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DESCRIPTION f 

Technical Field 

The present invention is directed to a system, 'method and apparatus for 
automating a laboratory process. More particularly, the present invention is directed 
to an automated tracking system and interface for use in the blood collection industry. 
^5 ^ R e la t ed Applicati on 

This ildhm the b e nefit of Provisional Pate n^ Applicaliun Serial No ~ 
XX/XXX,XXX, filed Apiil 2 8 , 
Background of the Invention 

Blood component therapy is a popular method of treating medical conditions 
10 or diseases. Components may be removed from a patient's blood circulation to 
eliminate unhealthy components. Blood components may also be inventoried for 
future transfusion into an ailing patient. Rather than transfusing a patient with whole 
blood, the patient is given packed red cells, platelets, or plasma depending on the 
condition that is being treated. For example, a patient suffering from anemia needs 
1 5 red cells, and treating that same patient with whole blood would be wasteful and could 
actually be detrimental to the patient. 

Blood components are removed from a patient's/donor's blood circulation by a 
process called apheresis. The removal of red cells and white cells is called 
cytapheresis or hemapheresis; removal of plasma is called plasmapheresis; and 
20 removal of platelets is called plateletpheresis. 

During apheresis, I.V. lines are inserted into a donor's/patient's veins. Blood 
is drawn from the veins and transferred to a cell separator machine where it is spun in 
a centrifuge to separate the components of the blood for collection. The speed of the 
centrifuge can be varied to isolate specific components by their density. Unneeded 
25 components are transferred back to the patient and reinfused. 

There are a number of facilities/organizations that are specifically set up to 



collect blood and blood components. Tracking donors, component handling, donor 
registrations, and the like are important aspects of the blood component collection 
industry. However, the blood component collection industry has long recognized a 
void in the automation of collection processes at collection centers. 

5 For instance, the current blood donation process generally comprises the 

following steps. First, when the donor arrive at the facility, he/she checks in at the 
front desk. The donor's paper chart is pulled, and his/her DMS record is pulled and 
checked. Next, the donor signs in, his/her weight is measured, and the weight is 
recorded on the paper chart. A name tag with a barcode is printed for the donor. The 

10 donor proceeds to a screening area where he/she is asked a series of medical 

questions. The answers given by the donor are recorded on the paper chart (new 
donors have additional questions). The donor's vital signs are taken, and these results 
are recorded on the paper chart as well. A small blood sample is taken from the donor 
and the protein level is measured. Again, these results are entered on the. donor's 

15 chart. 

Next, the donor proceeds to a waiting room where he/she waits to be called to 
a control desk. At this time, the donor's DMS record is updated with information 
from the paper chart. The collection facility designates a blood collection container 
and a blood collection kit for the donor. Bleed numbers are taken from a roll of 
20 preprinted barcode labels. There are three rolls of labels, each having different 

number ranges representing different blood types. The donor's name, donor number, 
and the date are printed on the appropriate label. Many labels are produced for each 
donor. One label goes on the donor's chart and several are applied to the collection 
bottle. 

Finally, the donor is escorted with his/her chart and collection bottle/kit to an 
assigned bed where the donor's blood is drawn. The actual volume ofblood drawn 
from the donor is manually recorded on the collection bottle. After the donation is 
completed, the donor's chart and the full blood container are transported to a 

processing desk. 

30 Most blood center operators have managed to automate processes such as 

donor registration, blood sample, and product handling but are unable to do much 
about the record keeping and tracking of the blood collection process itself. 
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The ability of the centers to automate blood collection data depends on the 
built-in data communication capability of the blood or blood component collection 
device. Unfortunately, most collection devices currently in use in this field have very 
rudimentary and/or proprietary data communication interfaces. This makes the task of 
5 connecting the devices to standard computing equipment cost prohibitive. 

For example, some of these devices transmit periodic binary data out of a 
proprietary pin-type interface. The periodic data rate and the maximum burst rate of 
these devices often approach or exceed the limits of most serial networks. Thus, in 
order to connect these existing collection devices to a serial network, new adaptor 

10 hardware, which is capable of interfacing with the proprietary interface of the 
collection device, is needed. Moreover, such a hardware add-on would require a 
communication driver for the host computer that receives the data from the collection 
device. This aspect would be even more complicated when high level messaging 
protocols are utilized for the communication. 

1 5 Healthcare devices have been included in computer networks. For instance 

U.S. Patent No. 5,857,967 (Frid et al.) is directed to a healthcare device which 
comprises a web server and medical information thereon, and which generates HTML 
files on the fly for providing such information to a client at a remote location using a 
standard browser interface. The healthcare device of the '967 patent is universally 

20 accessible via a communication network using open standard network protocols. The 
healthcare device includes the web server that exchanges messages with web clients 
using the HTTP and HTML open standard protocols on the communication network. 
The web server handles HTTP commands received via the communication network 
that specify a predetermined Universal Resource Locator (URL) for the healthcare 

25 device. The HTTP commands are used by web clients such as a web browser to read 
medical information including measurement data and optional related information 
from the healthcare device. The web server packages the medical information into the 
HTML format and transfers the information to requesting web clients on the 
communication network using the HTTP protocol. 

30 U.S. Patent No. 5,891,035 (Wood et al.) is directed to an ultrasonic diagnostic 

imaging system. The imaging system is capable of accessing images and information 
from internal and external databases by means of a web browser. Access to the 
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images or information may be over a local network or over the Internet. The browser 
may be used to pull in system preset data or reference images from a reference image 
library. 

Summar y of the I nvention 
5 The present invention is generally directed to a system for monitoring and 

tracking at least a portion of a blood component collection procedure in a blood 
collection facility. The system monitors the status of the blood component collection 
procedure performed on a donor and facilitated by an operator, and provides for 
remote monitoring of the procedure. The system generally comprises a blood 
10 component collection instrument, a blood component collection kit, a system server, 
an operator interface, and a display unit. 

The blood component collection instrument is provided for collecting a blood 
component from a donor. The donor is associated with a donor identifier that is 
unique to the procedure performed. The blood component collection instrument is 

1 5 also associated with an identifier. 

The blood component collection kit includes a blood component collection kit 
identifier. The kit is operably connected to the donor and the blood component 

collection instrument. 

The system server is operably responsive to the blood component collection 
instrument. Accordingly, the system server includes a software program comprising a 
plurality of segments defining a blood component collection process or procedure. 
The program is capable of monitoring the blood component collection instrument. 

The operator interface is operably connected to the system server. The 
interface includes a reader or scanner for entering information to be transmitted to the 
system server and integrated into the program for monitoring the blood component 
collection process. A display unit is operatively connected to the interface for 
monitoring the blood component collection process. 

Other features and advantages of the invention will be apparent from the 
following specification taken in conjunction with the following drawings. 
30 Rrief Description of th e Drawings 

Figure 1 is a block diagram of an embodiment of the present invention; 
Figure 2 is a structural diagram of an embodiment of the apparatus of the 
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present invention; 

Figure 3 is a structural diagram of a second embodiment of the apparatus of the 
present invention; 

Figure 4 is a flowchart of a daemon incorporated within the device of the 

5 present invention; 

Figure 5 is an illustration of a system login computer screen; 
Figure 6 is an illustration of a system welcome computer screen; 
Figures 7 through 34 are illustrations of multiple computer screens which are 
used during setup and administration of the system; 
10 Figures 35 and 36 are illustrations of computer screens which are used during 

the search function of the present invention; 

Figures 37 through 76 are illustrations of various computer screens which 
are used during the reporting function of the present invention; 

Figure 77 is an illustration of a computer screen used to monitor the 

1 5 instruments within a facility; 

Figure 77a is an illustration of information provided on the computer screen of 

Figure 77; 

Figure 78 is an illustration of a computer screen used during the dispatch 

function of the present invention; 
20 Figure 78a is an illustration of information provided on the computer screen of 

Figure 78; 

Figures 79 through 105f are illustration of various computer data input screens 
used with the wireless interfaces of the present invention, to 24a are illustrations of 
computer screens used during administration and setup of an embodiment of the 

25 present invention; and 

Figure 1 06 is a flowchart of a method for using the device of the present 

. invention. 
Detailed Description 

While this invention is susceptible of embodiments in many different forms, 
30 there are shown in the drawings and will herein be described in detail, preferred 

embodiments of the invention with the understanding that the present disclosures are 
to be considered as exemplifications of the principles of the invention and are not 
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intended to limit the broad aspects of the invention to the embodiments illustrated. 

O^rp T^ie present inven t ion is d irec ted t u an a ppai at us ur -sy st c m for - c o ll e cting :; — , 

using, and storing information in a biological fluid collection and/or processing 
facility ("facility"). The present invention can be incorporated into an existing 
5 facility's system Via an upgrade to existing hardware and software. The present 
apparatus provides \data connection between laboratory. instruments, including, but 
not limited to, existing^blood and blood component collection instruments, such as the 
Autopheresis-C instrument which is supplied by the Fenwal Division of Baxter 
International, Inc. located in Eteerfield, Illinois, those described in PCT Publication 

10 No. WO 01/17584, U.S. Patent Nos. 5,581,687 and 5,956,023, and U.S. Serial No. 
09/037,356, and biological treatmentinstruments, such as the pathogen inactivation 
instruments described in U.S. Serial NoNQ9/325,599, which are all assigned to Baxter 
International, Inc. and are incorporated by reference herein, and the collection 
facility's management information system whickr lends itself to automated tracing 

15 and/or tracking of donors and biological fluids datalogging. Traceability is provided 
via integration of donor, operator, soft goods, and instrument data. The present 
invention further automates event reporting which is required for regulatory 
-e omp li anc c- . - 

The system is designed for a biological fluid collection and/or processing 
20 facility as an accessory to the instruments used in those facilities. The general purpose 
of the system is to increase the efficiency of processing biological fluids and aid in the 
regulatory compliance process. This purpose is fulfilled principally through the 
collection of more information and more accurate information. Currently, facility staff 
must manually keep track of information such as by writing information on a 
25 clipboard, but the present system allows the staff and operators to skip the 

paper/manual steps. The system may also provide some of the following benefits: 
more accuracy and completeness in the data that is already being collected manually; 
more data collected for diagnostic use, which may give rise to better information with 
which to design or troubleshoot laboratory instruments; more data collected for use by 
30 the center for generation of ad-hoc statistical reports, which could relate any number 
of variables such as donors per day/per time of day, rate of errors, collection amount 
by type of donor, etc.; more data collected for use by the center to determine the 



efficiency and error rate of different operators, which in turn can inform decisions to 
institute better training or could substantiate a complaint against a facility operator; 
greater efficiency on the floor, due to less paperwork; lower costs due to less office 
paperwork; ability to research all the detailed information on a single procedure, or on 

5 the history of a single donor, as a way to find information pertaining to a donor 

complaint, or something wrong with the product, or any other complaint or error; more 
complete records and statistical and trend reports to help ease compliance reviews; 
accurate monitoring of the facility procedures; collection of information that may help 
the facility's staff improve their efficiency/workflow. 

10 The present invention also improves collection facility workflow by providing 

portable data input and monitoring devices and a method for tracking soft good 
utilization and coordinating restocking and reordering of the soft goods through 

remote access service. 

The present invention is suited for medical facilities where product integrity 
1 5 and traceability are critical quality factors. Typically, the instruments, laboratory 

equipment, as well as data input devices are connected to an Ethernet along with other 
data processing applications. The present invention is also suited for connecting 
legacy instruments that automatically transmit or can be configured to periodically 
transmit data via a serial or parallel interface and protocol converters. A computer 
20 acting as a server/gateway runs applications to receive the transmitted data and route 
them to database and hypertext markup language (HTML) applications. Each data 
packet bears a unique identifier which identifies the source of the data. 

Users can perform data query and reporting on a local area network, through a 
wide area network, over the Internet, or a combination of two or more of these, using a 
25 standard browser application interface. Real-time viewing and updating of device 
operation can be configured for any number of devices on the browser. In addition, 
the server also presents abbreviated data to a wireless personal digital assistant (PDA) 
also running a standard application browser interface for portable information and 
viewing and alarm and event notification. The PDAs are also used for data input 
30 (through a keypad touch screen, scanning, or other entering method - all used 

interchangeably herein) in association with an apparatus operation. Thus, the present 
invention includes open standard architecture in a heterogeneous apparatus 
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environment with real-time update and access of da., and portab.e da* viewing, 
rRnnrtins notification, and inputting. 

Referring ,0 Figure I. me system/apparatus .0 comprises a ft* network > 2 
compri • a sy tern serve, 34 inching a memory, a —ication d ver and an 

appiicln capable of running embedded javascript code and a, ,e.t one 

^ .t>r*hlv a PDA and/or scanner 26, but more preferably 
wir eless data interface, preferably a PDA an ^ ^ ^ 

enough PDAs and scanners to accommodate several iacility p 

n time and a wireless access point 28. - 
JJ? t^ecor.d^^^ 

^Lwa^^re^mponent parts and provides for inter-process 

, hardwareandso ft The flist network ,2 includes 

24c such as SLoW*- device by Lightner Engineenng located m San D ego, 
Ca i'f I or ,1™ device by Fenwa, Division of Baxter ,n— , .nc, 
5 deeded, a Xemet 30, and a system server 34 including a memory a 
5 :Iunica,iondriveX. h ea ph eresisins,rume nts, a communi—oco, 

ttmAt, P li??tmn with embedjedjayasiJiptxode^ 
""ttZ^ communicate via the .ntemet through a 

• t eh50 The network switch 50, which can be incorporated within the system 

, he information which it receives. J0 ides the 

Figure 3 shows a pair of networks 12, 14. The networ 

i n 1A Aaain the network switch 50 
communication link between the networks 12, 14. Again, 

25 information which u rece.ves. The first networ ^ ^ 

the instruments, a communication protoco. converter, and an HTML apphca, 
cap ab.e of running embedded javascript cod, ^ 

The second network .4 includes a second « 
44b 44c 44d, e.g. personal computers to run server and browser softwar 
44b, ^c,t tu, & k barcode scanner for setting 

one of the data interfaces 44a, 44b, 44c is equipped with a barcode 
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up facility operators and associating them with preprinted badges. The second 
network 14 also comprises at least one wireless data interface, preferably a PDA 
and/or scanner 26, but more preferably enough PDAs and scanners to accommodate 
several facility operators and/or donors at a time and a wireless access point 28. 

A central server 48, generally located at a remote site, may communicate with 
the first and second networks 12, 14 via the Internet using a communication link such 
as a modem, digital subscriber line, or the like with the network switch 50. The 
central server 48, therefore, can access data regarding the instruments 20a, 20b, 20c 
that are stored in the system server 34. 

The first network 12 is primarily established between the system server 34 and 
the instruments 20a, 20b, 20c. This first network 12 is not directly connected to the 
Internet or any other subnetwork except through the network switch 50. The network 
switch 50 is adapted to prevent unwanted communication with external servers and/or 
other means of data communication while at the same time being configured to 
1 5 forward useable Ethernet datagrams broadcast packets (UDP) to all ports. 

The system server 34 controls the distribution of data throughout the system 
10. The system server 34 runs an operating system, such as a Linux machine running 
SuSE 6.4 or more preferably a personal computer running Microsoft 2000. The 
system server 34 receives data from an instrument 20a via one of the serial/parallel to 
Ethernet converters 24a and/or other interfaces within the apparatus 10. Accordingly, 
the system server 34 includes one or more Ethernet cards to connect sets of apheresis 
instruments 20a, 20b, 20c to the system server 34 and at least one additional Ethernet 
card to connect the system server 34 to the facility's office network which is also 
connected to the central server 48. The system server 34 also runs a web server, such 
25 as Apache or more preferably. Microsoft Internet Information Server provided with 
Microsoft 2000. 

Each instrument 20a, 20b, 20c connected to the apparatus 10 is identified by a 
unique number such as an internet protocol (IP) address and a serial number. Certain 
legacy instruments provide framing bytes on data packets coming through a parallel 
port. The serial/parallel to Ethernet converters 24a, 24b, 24c gather data from the 
instruments 20a, 20b, 20c and deliver the data info an Ethernet frame buffer. The data 
is transmitted via the first Ethernet 30 to the system server 34. Server software takes 
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* • f motion It should be noted that the Ethernet 
converters 24a, 24b, 24c are necessary for certain lega y 
needed in every application of the present system 1 a 

Re ferring to Figure 4, the in— 20a is serial/parallel 
system 10. Theinst^^ 
toEthernetconverte^^^ 

(user datagram protocol/internet protocol (UDP/IP) packets) 

•♦c thP I IDP data packets to the system server 34. 
transmits the UDP data p rf two separa te functions. 

The software within the system server 34 performs F 
lnesonwai . c0n5 , 90b 20c This function 

receives the UDP packets from the firs. Ethernet 30. T 

HTML fi.es to web Oients by sending and rece.vmg rent te ™*o 

data . According!,, the server software cotnprtses separate moduies P 

modules within the system server 34. The core mo fed 

^ i ^ *nd caches information from the instrument zua tnai 
database module 62 and caches in The CO re module 60 

on a frecuent basis via data interface 44b and/or the PDAs 6. 

business logic. ^ ^ rf ^ instrume nts 

First the core module 60 receives uur v 

contains a protoco, describing network — ™- ™ 

with a bootp server which contatns the IP addresses workstatio n to 

- - r - — * •: ■ — — 

30 without requiring a hard or floppy dtsk drtve. The converte 

converter hoot procedure modu.es are , oftw- ^ 

The data transferred from the instruments 20a, 20b, 20c 
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can be used to create HTML web pages for monitoring the instruments via a structured 
query language (SQL) open database connectivity interface (ODBC). The core 
module 60 writes to the database module 62, which includes a SQL database server, to 
save and manage the instrument data. Javascript is used to create database tables on 
the SQL server and creates definitions for each table and field. The SQL database 
server stores all apparatus data except for high resolution logs. 

The SQL database server preferably uses MySQL and more preferably 
Microsoft SQL Server. The SQL database server saves the data into a disk array. Java 
code within the HTML files provides a SQL interface to the SQL database server 62. 

A web module 64, comprising the web server, can access the SQL database 
server using the ODBC interface. The web module 64 serves the web pages on the 
second Ethernet 40 so that the instruments 20a, 20b, 20c on the first Ethernet 30 are 
not interfered. The second Ethernet 40 allows standards such as javascript and 
hypertext preprocessor (PHP) codes to be viewed. The javascripts and/or PHP can be 
used to query and search the database. 

The web module 64 communicates with the core module 60 via RMI data 
transmission. The core module 60 sends RMI data to the web module 64. Hypertext 
transfer protocol (HTTP) data generated by the web module 64 are served to and 
received from the web browser 44b via the web module 64 and the second Ethernet 
40. The web browser 44b can act as a central workstation for monitoring the 
workflow within the blood collection facility. HTTP data can further be served to and 
received from the facility's donor management system (DMS) 65. 

A mobile module 66 controls the system server's 34 communications with the 
PDAs/scanners 26. Thus, PDAs/scanners 26, such as the Palm Pilot™ by Symbol, are 
also a source of data to the system server 34. Preferably, each PDA/scanner 26 
includes a wireless RF link and a built-in bar code scanner. The wireless feature of 
the PDA/scanner 26 allows the users to move freely in a room such as a blood center 
and scan barcoded material knowing it was logged into the database. The human error 
from manually writing down a number onto a log sheet is, thus, eliminated. 

The core module 60 communicates with the PDAs/scanners 26 via the mobile 
module 66 by transmitting and receiving RMI data to and from the mobile module 66. 
The core module 60 can also serve data regarding the instruments 20a, 20b, 20c, such 
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a- ..v or status to a PDA/scanner 26 in real time or near 
as an instrument's screen d.splay or — * » „ the sys ,em 

real time. Thus, the wireless access pom, 28 prov.des 
server 34 and the PDAs/scanners 26. ^ ^ 

The mobile module 66 com.nun.ca.es HTTP d 
5 p DAs/s can„ers. The PDA/^er 26 can be = ; ^ ^ ^ ^ in _, 
disposable kits, bleed numbers, donor ID card, ope *or I ^ ^ 

and logged electronically and wirelessiy 

Windows 2000 opera„n g sy,em. ™e « ^ ^ —s 

15 nead q uar,ers(HQ)server. ^ cemn, 

throu g han,Pnetwor ^ ^ ste . ^ cen 0 a, server must . 
system servers 34 due to me id B Ther e is not a wireless base 

capable of con.ct.ng any remote server a, a,y «m, ^ ^ 

station 2S or in— 20a, 20b, 20c a. the HQ (jp) 
20 Other 
Personal computers ^^J^^^ capability can also 
computer dev.ces w,.h a brow* ^ ^ 

connect ,0 the server w„h ptoper cun* ^ ^ ^ ^ 

Similar to the system server 34, the centra 
25 perfcrmpredeterminedmnc^ 

contains a central management module 74, a databa 

^ecen.ralm^^ 
30 " d t^^L-. - 
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necessary to start the initial facility network upgrade process, including a setup 
program. 

The central database module 74 houses a database composed of all the 
facilities' databases merged together. The central database module 74 is designed to 
5 facilitate the database merge by insuring that the definitions of unique keys do not 
conflict. All data is collected by and lives in the facilities' database modules 64. 
There can be many such facility database modules 64 in communication with the 
central server 48. The system servers 34 are the servers for all communications with 
the donor management systems 65. 
1 0 Optionally, a company operating several facilities, each having its own system 

server 34, may also have a dedicated central database. This dedicated central database 
is equivalent to the database module 64 except: (1) many of the functions of the 
database module 64 cannot be used because the central server 48 is not connected to 
any wireless devices or apheresis instruments; and (2) an additional program is needed 
to run the dedicated central database with the contents of the several system databases. 
This synchronization program communicates directly with the system servers and 
updates any changes from the system server 34 to the central server 48. 

In use, the facilities provide inputs to the system server 34 through an HTTP 
call for each procedure which is initiated from their donor management system before 
20 the system server will store data for the procedure. The facilities may issue HTTP 

requests for data from their system servers 34 for limited bleed summary fields, usmg 
a programmatic interface, in addition to the HTTP browser-based reporting interface 

from the central server 48. 

The present apparatus 10 may be called a "distributed system;" however, the 
25 system server 34 operates independently as if it were not part of a distributed system. 
The central or HQ server 48 takes initiative to copy data in both directions as needed. 

The system server 34 always operates in server-mode with respect to 
communications with headquarters and other systems, and never operates in client- 
mode. The donor management system and the central server 48 operate in client-mode. 
30 In server mode, the system server 34 waits for requests and does not initiate 
transactions with other servers. This achieves the benefits of centralizing data 
management functions (like backups) while retaining the robustness of independent 
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used in any biological fluid election and/or processmg facl.ty 
from the spirit of the invention. 

SOFTWARE j M .„ftware components for reporting, 

The system 10 of this embodiment mcludes software P 
business administration, and technical facility requirements. 

B£BaIliBS • d the system 10 provides interactive reporting capability to 

On the reporting end, the system .op 

common computing platform, essentially »*"^ ^ > „ viewing> but 
« also printable. Ml re^rts may reo.u,re user s^non ^ 

' ^i:i;r::r:b^:rr 

:;u:r:onnameeach,.me,itshouldbe^^^^ 

The local time zone of the database server must be taown y ^ ^ 

time outputs in reports are stored and reported m the local ..me 

rcferences a pre-defmed table of weekiy P ^ 
25 items representing hours, as in this example: mon-8, 8, 

sat-*, sun-0. ^ goals compared to actu al 

Other reports may reference rf ^ „ 

handle these cases. Goals are Qinerc 
30 week, month, and year. 

Ba ^^minis,ra,io„end,,hehigh — 
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time history, e.g. second-by-second, of an instrument's output variabies. The log » 
filed so that it can be easily located in the file system, but no, interactive* witmn the 
software. The facility management has the option of turning the high-resolufon 

logging feature on or off. 

The high resolution log is generally stored at one second intervals for each 
facility instrument whiie the instrument is in run mode; i.e. during a operation, and ,s 
not stored at all while not in a bleed. This is accomplished by suspending loggmg ,f 
the instrument's mode code remains a, 1 (indicating paused or not in a operate) for 
more than one minute. When it changes to another value, logging is resumed. The 
high resolution log is stored in a FIFO-type queue as disk space permits, at least one 
month of logging. 

The following variables must be stored for each log interval: local date and 
time contents of the instrument's run packet (as described below). 

Further to the business administration end, a medium-resolution log 1S stored 
to provide an occasional "snapshot" of the instrument's output. The medium 
resolution log is stored for facility purposes and is available the generation of reports. 

The medium resolution log entries are generally made at these times: when any 
alarm/alert is issued by the instrument during any phase of a procedure; at every 
instrument keystroke; at every minute, if there hasn't been any log entries in the last 
20 minute, but only if the instrument is running (i.e. mode is not 1). The one-mmute 
recording feature is controllable (on/off) at the site level. 

In the case of an apheresis instrument, the following variables are stored xn the 
medium-resolution log: date/time; reservoir sensor; PI pressure; P2 pressure; cuff 
pressure; M2 flow rate; plasma flow rate; cycle #; display; plasma volume; clamp 
25 status (4 clamps); mode code; keystrokes. 

The administration end also includes a setup and procedure-related log (e.g., a 
bleed-related log). In order to meet the purposes of cost reduction and informaUon 
availability, information on each procedure is stored in an interactively available form 
for a period of at least two years. The facility has the option of purging old data stored 
30 at the facility level. Meanwhile, the headquarters system staff has the opUon of 

archiving old data stored at the HQ level. Every log entry includes the absolute date 
and time (i e. GMT, not local time). These general data requirements apply equally to 
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the medium resolution logs (above). 

In the case of an apheresis facility, the stages of the procedure are the 
instrument setup, procedure-program, arm-prep, remove-plasma, and disconnect 
donor. Instrument setup is performed without reference to any specific donor, and ,s, 
therefore, not linked to the donor or bleed in the database, (although it may have to be 
linked retroactively). The bleed procedure (from procedure-program through 
disconnect donor) is identified by a unique bleed number provided by the facility's 

system. . _ . T 

The events that are collected and logged include the those shown ,n Table 1 . In 

addition, the system allows even, types to be added with a minimum of redes.gn, 
because the selection of events to be logged is a requirement that could conceivably 

change after initial testing. 
Table 1 : Event Logging 

I Event Type 
Machine Setup 

i Procedure Program 



O 



Prep Arm 



I Venipuncture 

I Response to Remove plasma 
alert (donor still connected) 



O 



Response to Disconnect 
Donor Alert 



Response to Reboot-Resync 
Alert 



Data to Log for This LvenT 

Operator ID 
Instrument ID 
Products 

Operator ID 
Instrument ID 
Bleed No. 
Donor ID 
P lasma Volume 

Operator ID 
Instrument ID 
Arm - Left or Right 

Operator ID 
Instrument ID 

Operator ID 
Instrument ID 

Plasma Volume Collected (user 
entered) 

Reason-List for UON or UUN (over or 
under draw) 

Operator ID 
Instrument ID 
Donor Reaction - yes or no 
Free-F orm Not es^ 

Operator ID 
Instrument ID 
Bleed No. 
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Event Type 


O/A 


Data to Log for This Event 






Donor ID 


Response to All Utner 


A 

A 


{ r ^\r\£*ra1' t*\r TTl 
l^pcrdlOr ILJ 


A 1 — / A 1 ~ „i. „ 

Alarm/ Alerts 




insirumeni i u 






Action List 






Original Alarm/Alert Text 






Time of Original Alarm/Alert 






Procedure Continued? 






Outcome List 






Free-Form Notes 






Other Actions 


Product Performance (used 


r\ 
KJ 


Onprotr^f Til 

L^pcrdiur llj 


when any part of a kit is bad 




Tnctn impnt TD fontional^ 


and is discarded - provides 




rTOQUCl r aiiurc : 


information for the kit 






supplier) 




Prnrlnrt TD 

1 IUL1UV--L LLJ 






T r\\ XTr* 
IvOL INO. 






Prohlpm Code and 






Df*Qprintinn Aispd onlv 

i/V^vl ^UOWU KJ Ll.± J 






if "fcii liit*** ic Vpc 1 

11 IctllUIC lb ICD^ 






f^nmrtrin F»nt C~^nHp and 






T^^crTirvH on AiQ£*H onlv 

UCj^I 1LH1U11 ^UJt(U \JllLy 






if failure is Yes^ 






Videojet No. (only used if 






component is "separation 






device") 






Reason (used only if 






failure is No) 






Notes 


Move Donor to a Diilerent 


U 


L^peraior iu 


Instrument 




insirumeni iu ^uic new 






one) 






Rleed No 






Donor ID 












Was v^UliCL'UUIl V^UllLdlllCl 






Transferred? 






Plasma Volume Collected 






(only if answer to 






previous question is 






Yes) 






Outcome-List 






free-form notes/reasons 


Second Venipuncture (used 


O 


Operator ID 


only as a subroutine of other 




Instrument ID 


event types - see screen 




Outcome-List 


layouts) 
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Event Type 


O/A 


Data to Log for This Event 


Manual Saline 


O 


Operator ID 
Instrument ID 
Reason-List 
Outcome-List 
Free-Form Notes 


Donor Reaction 


O 


Operator ID 

Instrument ID (optional) 
Outcome-List 
Free-Form Notes 


Procedure Termination 
(Abnormal 
disconnect donor) 


O 


Operator ID 
Instrument ID 
Donor Reaction? 
Reason-List 

Reservoir contents Manually 
Reinfiised? 

Cell Loss Volume (only ask 
if the answer to the 
previous question is No) 

Free-Form Notes 


Other 


O 


Operator ID 

Instrument ID (optional) 
Bleed No. (optional) 
Free-Form Description 
Free-Form Resolution 


Override Log 


O 


Operator ID 
Instrument ID 
Free-Form Notes 


Accuracy Messages 


O 


Operator ID 
Message 



1 0 In regard to Table 1 , in the O/A column, an "O" indicates that the operator 

initiates the logging from a menu, and it is optional. An "A" indicates that the logging 
is a required response to an alarm/alert. 

The operator is identified by a unique badge number and log-in ID. 
The "products" entry is a list of up to ten components of two barcode scans for 
1 5 each component. The first barcode identifies the product number. The second barcode 
identifies the lot number and expiration date. In some cases, only one component will 
be used, and in other cases, five will be used. The system allows up to ten for future 
needs. 

The bleed number is printed on a barcode label generated by the DMS, and is 
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scanned only once. The bleed number is tied to all future events until the completion 
of the remove-plasma event occurs or any instrument-setup event occurs. If the donor 
is moved to a different instrument, uses a different kit, is seen by a different operator, 
or any other changes occur, it is still the same bleed number as long as the same 
5 collection container is used. 

The donor is identified by unique donor number. Donor tags may be printed 
with a photo ID upon entry to floor, or the donor number may be scanned from a paper 
chart. The ID number is a constant and unique identifier for the donor. 

The Apheresis instrument is identified by serial number. For the O-type 
10 events, it must be operator entered (scanned), but it is system derived for the A-type 
events. 

The 'action list' for alarm/alerts is a different list for each alarm/alert type, 
including such items as "check line", "check pump", etc. The user must be able to 
select one or more items from the action list. The 'reason list' works the same as 

1 5 action lists, but is used when a reason for an operator action is required. The 

'outcome list' works the same as action lists, but it includes occurrences following the 
event in question (e.g. procedure continued, terminated, etc.). There is only one 
customer-defined outcome list which is used for all types of log entries where listed. 
The 'Override log' event is only available in recovery mode, not as a general 

20 purpose log entry. It is intended for supervisor use to log a change to an existing iog 
entry. It does not change the bleed summary or erase any data, or change what is 
shown in reports. 

The 'Accuracy message' log is not operator initiated. It is automatically logged 
when exception messages are shown as listed under 'Operational Accuracy' 

25 requirements. It logs the message that is shown to the user without user intervention. 

In addition to and separate from the log of events listed above, summary data 
for each bleed or partial bleed is stored. These records are not specific events, but are 
totals or averages over the whole bleed. The summary values are calculated either 
from (1) data provided by the apheresis instrument (the same data that optionally 

30 forms the high-resolution log); (2) the log of operator events; or (3) from the customer 
donor management system. The summary includes the following data items: bleed 
number, donor number, date and time of most recent instrument-setup logging, date 
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and time donor arrived on floor (captured from donor system), date and time of arm 
prep logging, date and time of venipuncture logging, date and time procedure started 
(from apheresis machine), date and time of remove-plasma logging date and time of 
disconnect-donor logging, all products/lots used in the bleed, apheresis instrument (if 
5 more than one instrument, store latest instrument used), flag if more than one 

apheresis instrument used, operator who performed instrument-setup (if multiple, store 
latest), number of alarm/alerts associated with instrument-setup, number of 
instrument-setups performed, operator who performed the procedure program (if 
multiple, store latest), number of alarm/alerts associated with procedure-program, the 

1 0 operator who performed venipuncture (if multiple, store latest), number of alarm/alerts 
associated with the run, the operator who performed remove-plasma (if multiple, store 
latest), the operator who performed procedure-end (if multiple, store latest), total 
number of alarm/alerts, the latest AC rate set (it could be changed mid procedure), the 
total plasma volume collected as reported by the apheresis machine, total plasma 

15 volume collected as reported by the user, the remove-plasma event, target plasma 
volume as determined by a calculation based on the facility system, total VP time - 
calculated by disconnect time minus VP time, or use a value from zeropage, total AC 
used - based on volume of AC pumped for the current bag + (number of bags used 
completely * volume of each bag), any overdraw? (defined by site-entered value, e.g. 

20 8% over the programmed volume), any underdraw? (defined by site-entered value, e.g. 
8% under the programmed volume), any no-take? (defined by site-entered value, e.g. 
less than 100 ml) cell-loss volume (if abnormal disconnect), donor reaction - yes or no 
(based on the existence of a Donor-reaction event, or the donor-reaction field set in 
the Disconnect-donor or Procedure-termination events), reviewer, review date, review 

25 notes, whether the bleed is classified as an exception - yes or no (in order to determine 
this, a center-level setup function must be available to select which of these things 
indicates an exception: 2nd VP, procedure termination, cell loss, donor reaction, 
over/under-draws, misprogrammings, "other"-type log entry, reboot-resync log entry, 
and the reason that the bleed is classified as an exception (e.g. "cell loss" or "2nd 

30 VP"). Additional fields may need to be stored in the summary in order to produce the 
required reports. 

Only the procedure-program, change-instrument, and reboot-resync associate 
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the bleed number to a instrument. All other events event types are logged in relation to 
the instrument. Therefore, in order to satisfy all of the above requirements, the system 
tracks the events associated with the instrument(s) in use, and calculates the bleed 
summary based on that information. The bleed summary is be calculated after the fact 
5 without user intervention. In other words, there is not a user input required to signal 
the end of a bleed. For example, if a venipuncture event is recorded, and the next 
event for the same instrument is an instrument setup event, then it is assumed that the 
previous bleed ended in some unknown way (perhaps a power failure), and that the 
bleed summary record should be stored with incomplete information. 
1 0 The bleed summary has the option of an attached review (reviewer, date, and 

notes), which an auditor with the appropriate privileges shall be able to add and edit. 
The review information must be visible to all users who have access to the bleed 
summary. 

Each logged event may be edited by a supervisor who has appropriate access to 
1 5 the system. However, the old version of the record must also be stored and visible for 
comparison. Only the new edited version will be used for calculations in reports. 

Outside of the bleed events detailed above, the system must log these 
maintenance events, along with the operator who performed them, the absolute date 
and time, and the Apheresis machine. 
20 Table 2: Maintenance Event Logging 



Event Type 


O/A 


Data to Log for This Event 


Daily Maintenance 


O 


Operator ID 
Instrument ID 
Actual Weight for Weight 
A 

Actual Weight for Weight 
B 

Cleaned Instrument? 
Free-Form Notes 


Weekly Maintenance 


O 


Operator ID 
Instrument ID 
Step That Failed, if any 
Free-Form Notes 


Monthly Maintenance 


O 


Operator ID 
Instrument ID 
Step That Failed, if any 
Free-Form Notes 
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Event Type 


O/A 


Data to Log for This Event 


Field Service Report (FSR) 


O 


Operator ID 
Instrument ID 
Field Service Completed? 
Reason-List (only stored 
if FSR NOT completed) 
Free-Form Notes 


Out of Service 


0 


Operator ID 
Instrument ID 
Reason-List 
Free-Form Notes 


Back in Service 


0 


Operator ID 
Instrument ID 
Resolution Technician - 

Free-Form 
Reason for Service 

(pick list) 
Part Replaced (pick list) 


Audit Log (to be logged only 
by auditors with appropriate 
permissions) 


O 


Operator ID 
Instrument ID 
Free-Form Notes 



In regard to Table 2, Weight A and B for daily maintenance references two 
pre-defined calibration weights, such as 500g and lOOOg, which may be customer 

10 defined. When an out-of-service event is logged, the system automatically removes 
the instrument from the inventory so that attempts to use it will result in the 
appropriate alarm/alerts as described elsewhere. However, the back-in-service event 
does not reinstate the instrument. This step is done separately. 

The system also stores the history of each instrument added to or subtracted 

1 5 from the facility's inventory. The inventory function is not associated with the 
maintenance event logging of the out-of-service and in-service events. 

For each instrument, the manufacturer identity, the model name/number, the 
serial number, and the enabled/disabled flag are stored. Each time an instrument is 
added to the inventory, the following information is also stored: the location (center), 

20 the date added, the bed number (e.g. 1, 2, 3..., as opposed to the long serial number), 
and any notes. Each time an instrument is removed from the inventory, the following 
information is stored: location - from where it was removed, the date removed, and the 
location or description of where/why it was moved. An instrument that is not in 
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Th e system also mamtatns a log of the d,sp informatio n 

rele ased for use, the d a sterillzatlon 

quarantined, if quaranttned, the reason fo q ^ 

wan, to use the fields "sterilization certificate on file and 

Lie W hich may be edited via a setup function: the pr d. c ^ g 
.. kit s", "solutions", etc., the manufacturer's produc numbe, he 
5 product number -this Renumber that appears on barcodes), 

description. ne rformance issues by problem code, a 

lookup table of problems must ex.st. Each spec P ^ 
problem group (e.g. "leaks in tubing" belongs to the general g 

in P ut . . oi„rm/alerts- (1) alarm/alerts 

There are two general types of operator alarm/alerts. ^ 

h P pn dismissed by an authorized operaiui a 
Alarm/alerts that have not been dismisse y t he assumed to have been read 

, /ownueue An alarm/alert may not be assumed xo 
active in an alarm/alert queue. A r v, a s Dressing an OK button). 

0Pera,0rS eI . rihopcratorcanbeauthorizedforanysubsetof 
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alarm/alert. This affects reporting only. 

If an operator is not authorized to handle an alarm/alert, he can override the 
restriction by getting the approval of any supervisor, in the form of a badge-scan. To 
handle this requirement, the administrator must be able to select which operators are 
5 supervisory during setup. 

Each alarm/alert type can be set up by the center supervisor to be one of three 
status levels: ignored, auto log, or manual log. The 'manual log' type requires a log 
entry to be entered to dismiss the alarm/alert. The 'auto log' type allows the operator 
to dismiss the alarm/alert and automatically makes a log entry. 
1 0 Each alarm/alert type can be flagged by the facility supervisor to be any 

combination of the following states: operator-related, disposable-related, instrument- 
related, instrument- setup-related, procedure-program-related, procedure-run-related, 
critical, count-for-reports (makes it appear on alarm/alerts by operator and instrument 
report). 

1 5 Single-user devices (PDA devices) may be available for each operator to 

interactively input data and process alarm/alerts. These devices are operator-specific, 
not facility -wide. The items that are displayed in this context are: full alarm/alert text 
for alarm/alerts routed to the current operator. 

Routing alarm/alerts will depend on the hardware to be used. If mobile devices 

20 are used, then alarm/alerts will be routed to operators whenever the system knows that 
the operator is using a certain device. The alarm/alert must not interrupt the current 
entry screen. All operators may view all alarm/alerts (but only authorized operators 
may dismiss or log resolutions). 

At login, whenever a password is required, the operator must either scan a set 

25 of instruments or press "All" to associate a certain set of instruments (or all 

instruments) with the operator. Alarm/alerts are initially routed only to operators 
associated with the instrument, but after a site-selected timeout period, the alarm/alert 
routing is widened to go to all operators, and the signaling (beeping or flashing) 
becomes more pronounced. 

30 As an exception to the above routing requirements, a nomogram check alert 

will always be routed to the operator who logged the procedure-program instead of the 
operators associated with the instrument. 
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Instrument alarm/alerts are predefined by the instrument firmware. The 
present system will use the same alarm/alerts that the instrument generates. 

System-generated alarm/alerts will include the following type. If a bleed is 
apparently in progress (based on logging of events by the operator) and no procedure 
5 log data has come from the instrument in the three seconds prior to the operator's log, 
then an alarm/alert must occur to warn the operator that the instrument is not working, 
or the network is not working or not connected. 

If an instrument is detected to be in run mode but the instrument is not an 
authorized device, an alarm/alert will occur to warn the operator that an unauthorized 
1 0 device is in use. An alarm/alert is generated when the instrument is powered up, as a 
diagnostic tool to verify that it is connected properly. 

An alarm/alert is generated if there is a mismatch between an instrument record 
and its previous record, such as could occur if the same Ethernet MAC address is used 
on two devices, or if someone swaps the networking connections or devices. This 
1 5 requirement is only necessary if the system design would potentially permit such an 
error to occur, such that the actual source of the data is unknown. 

If the system is rebooted during one or more bleeds, it must figure out which 
instruments are in a bleed process after it comes back on-line. To associate the 
running instruments with the data that may have been collected before the crash, it 
20 generates a reboot-resync alarm/alert for each instrument that is running. The 

operators? responses to this alarm/alert re-associate the instrument with the donor and 
bleed numbers. 

The facility has the option of running as many as ten independent display 
screens at the same time, and is able to choose which type of display to show on each 
25 screen. These are intended for mounting where all floor staff can easily view the 
screens. All displays support standard monitor sizes and resolutions. 

One status screen is the overview screen. The overview screen includes highly 
summarized compacted data items shown for each instrument. Depending on the 
monitor size and number of instruments, the overview screen may be scrollable, or 
30 two or more screens may be needed to display the status for all instruments. The 
overview screen should match the floor layout ofthe instruments in groups or areas. 
Another status screen shows the instrument number (e.g. 1, 2, 3, not the serial 
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number), alarm/alert conditions - just a highlight if there is an active alarm/alert, 
instrument display text, the amount of plasma collected in this procedure, a bar chart 
of plasma volume per programmed amount, the operating state of the instrument (out 
of order, not in use, in use, or on reserve), and an indicator if the instrument is 
5 associated with at least one operator. 

Another status screen displays the full alarm/alert text for all active 
alarm/alerts, with the related instrument 

Another status screen is a dispatch screen. The dispatch screen is similar to 
the overview screen. However, the dispatch screen adds an interactive function. The 
1 0 dispatch screen shows these data items in the same layout as the overview screen: 
instrument internal number (e.g. 1, 2, 3, not the serial number), a 
bar chart of plasma volume per programmed amount, the operating state of the 
Apheresis machine (out of order, not in use, in use, or on-reserve) 

The dispatch screen includes a function which allows an instrument to easily 
1 5 be placed on reserve. "On-reserve" is a pseudo-state of the instrument that is only 
relevant within the dispatch screen itself, and is never communicated or stored in any 
other part of the system. When on reserve, a instrument stays on reserve for 20 
minutes or until its actual state changes to a run state. 

The system comprises two levels of accuracy checks: (1) dual entry - the most 
20 stringent, and (2) confirmation - slightly less stringent but quicker. The system 

requires dual entry of the target collection volume because accuracy of this entry is 
paramount. One entry is inputted into the instrument as is currently done. The second 
entry is calculated based on the donor weight, which is passed automatically from the 
donor management system (DMS). The calculation is based on a mapping of weight- 
25 ranges to volumes (nomograms), which will be controlled by a setup function. If the 
calculated nomogram and programmed value do not match, an alarm/alert is issued. 

The system also requires dual entry of the donor number and bleed number. 
These numbers are originated by the DMS, printed on barcode labels, and also 
inputted pushed into the system. The system compares barcode scans with the directly 
30 passed values and prevents entry of the scanned barcodes if they do not match. The 
comparison of donor and bleed numbers is done as a unit, not each separately, since 
there is only one correct donor number for each particular bleed number. 
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If an event is logged, but it is out of sequence with the previous event on an 
instrument, then a warning is displayed but the events are logged as usual. 
Sequencing is determined by a table of A-B pairs where "A" and "B" are two events 
and "B" normally follows "A". The table may be determined at design. For example, 
5 if a venipuncture follows a donor-disconnect event, this signals a warning because the 
entry (disconnect, venipuncture) is not in the sequence table. An exception is the order 
of the arm-prep and procedure-program events which may be interchanged. 

If an expiration date is scanned in any context, and the date is earlier than the 
current date, then a warning is displayed and the operator may continue or go back and 
10 scan a different item. 

If an instrument is scanned, and that instrument number is not an authorized 
and enabled device, then a warning is presented and the operator may continue or 
cancel. 

If a lot number is scanned, and that lot number has not been entered as a 
1 5 released lot, then a warning is presented and the operator may continue or go back and 
scan a different item. In order to handle this, the facility management must enter 
released lot information as defined under data storage requirements - disposable lots. 

If a lot number is scanned and that lot has been entered as a bad lot, then a 
warning is presented and the operator may continue or go back and scan a different 
20 item. In order to handle this, the facility management must enter lot numbers and 
associated messages in a bad-lot list, with product numbers added by operator, and 
dates. The list may also be broadcast to all other facilities. 

If a bleed number is scanned/entered, and that number is already in the 
database, a warning is presented and the operator may continue or cancel. 
25 Scanning a barcode is an insufficient action to commit permanent data storage 

of information. Any scanned input must require the operator to use keyboard or 
touch-screen input to confirm/verify the scanned values. 

If an instrument setup is logged, and the instrument has not had a daily weight 
scale verification logged within the last 24 hours, then a warning is presented and the 
30 operator may continue or cancel. 

If an instrument setup is logged, and the instrument has not had a field-service- 
report logged within the last year (or time period specified by customer), then a 
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warning is presented and the operator may continue or cancel. 

When an abnormal-disconnect event is logged, the computed value of cell loss 
volume must be suggested to the user, who may accept or change the suggested value. 

In order to assist the operator in making the correct log entries, the operator 
5 must be able to view all the log entries that have been made for any bleed that is in 
progress. For bleeds that have ended, this information is available in reports. 

If a calibration weight is entered in the daily maintenance log, and the 
measured weight is more than some pre-defined percent variance, then a warning is 
presented and the operator may continue or cancel. 
10 If a venipuncture event is logged and the donor requires a blood sample, a 

message is given to this effect. 

When an Hb detect alarm is logged, the operator is notified what number Hb 

detect this is for the bleed, e.g. first, second, etc. 

When a venipuncture event is logged, the operator must re-scan the bleed 
number, and if the bleed number does not match the bleed number scanned for the 
procedure-program event on the same instrument, an error message must be presented, 

and the operator may not continue. 

The system database server is secured by password protection (at least), and 
the passwords are different for each installation and changeable by the administrator at 
20 any time. Read and write access to each of several different areas of data are 
separately controllable. 

Users are identified by a user ID, password, and scannable badge number. The 
user must log on using the user ID and password. Passwords are 4 or more characters 
in length and may not be the same as the login ID. 

Relaxed security is tolerated in the case of a mobile device, under this 
condition: If the device was used by an operator in the past hour and the same operator 
logs in again on the same device, no password is required, only the operator's ID 
number is required. 

Relaxed security is also tolerated in connection with a mobile device where an 
30 operator logs on using the user ID and password, and scans his badge number, then 
when he/she logs on again during the same shift (a center-selectable time period), only 
the badge number is required to validate the operator. 
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Users and passwords are maintained a, both the facility level and the 
head^s ieve>, separately. Facility-ieve, users wil. only have iogin access a. tha, 
facility. Headquarter-level users will have login access a. all facilities. The 
disunion of the two levels does no. gran, any privileges ,0 the use, Rather, ,. only 
5 specifies at what site the user records are managed. 

Operators are able to choose their own passwords and change them a. any 

time, but not on a mobile device. 

To handle forgotten passwords, the system includes a method for an 
administrator to reset a selected usefs password to a random-4-digi. number, then the 
10 operator must be forced to change his password on the next login, and w,,hm 

minute, After 1 5 minutes the account will be unusable until the password ,s reset 

again by the administrator. 

To handle occasional password changes, the system includes a means for 
allowing an administrator to flag all accounts to force a password change on the next 

15 '° g ' n ' All network devices must be authorized by manually entering their serial 

numbers or MAC addresses, including wireless devices, such tha, a new, unrecognvzed 
device cannot successfully send or retrieve data. 

The system may support as many as 100 instruments and up to 20 operator 
20 devices. These will generally be in a 6:1 ratio. 

The headquarters system must support merging the databases from up to 90 

facilities. n 

The system monitors operator performance. A, maximum scale when 
devices are in operation, the system should never enter into a sustained period of slow 
performance lasting more than one minute, where slow performance is defined 
second lag between operator input and the next prompt. A lag of up to one second ,s 
acceptable under normal operations. 

Because of the possibility that the facility will develop software hnkmg to the 
system, and that software could place unforeseen demands on the system, such as 
excessively large or non-optimized database queries, facility extensions must be kept 
as an exemption to the performance requirements. The facil«/s extensions can be run 
during hours of low-use or non-use of the instruments if this turns ou, to be a problem. 
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The system must be able to operate continuously for at least 18 hours at full 
utilization, out of each 24-hour period. The system may be designed to run internal 
downtime procedures, in which case the instruments may not operate during that time. 
The downtime procedures may not last more than 4 hours in any 24 hour period. The 
customer must have the option to schedule the downtime procedures at a time 
appropriate for them. Each facility has the option to continue running the system 
during the remaining hours in order to run software extensions that interface to the 
system. 

Technical Facility Requirements 

Underlying many of the technical requirements is the fact that, typically, there 
will not be IT staff available at the facilities, and so the system must be relatively self- 
correcting and require few inputs. 

A diagnostic mode is provided to ensure that the mobile devices can 
communicate full-circuit to the instruments. 

The operational state of the system server (i.e. running or down) is detectable 
by the instruments. 

There are a number or reliability requirements. For instance, the mobile 
devices and instruments reliability do not have an impact on system reliability because 
they are redundant and replaceable. The number of extra mobile devices needed to 
account for failures can be determined after installation. However, the reliability of 
non-redundant commodity equipment, such as the database server, is not considered a 
formal requirement 

In the event of theft, fire, or irreparable physical damage to the database server, 
such as disk failure, the system must be able to be rebuilt with new components and 
loaded with archived data within 12 hours, and the number of hours of data loss in this 
case may not exceed 4 hours. The high resolution logs are exempt from the data loss 
requirement. 

In the event of unexpected shutdown of the server, or crash, or power loss, the 
server reboots and continues operations* with a maximum data loss of the period one 
minute prior to the shutdown. When the system is rebooted, it resumes logging data 
related to bleeds that were started or were continued during the downtime. 

The system is be fail-safe between components, i.e. failures in one component 
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may not cause data loss or the need to reboot the rest of the system. In particular, 
communication failures to a mobile device are recoverable without user intervention, 
and power loss of any component including the central server should not require user 
intervention other than restoring power. 
5 As conceived, the instruments and NetDev devices (where necessary) use 

UDP/IP network packets. Therefore network packets are verified at the UDP level. As 
a result, there is some data loss of the high-resolution procedure logs. The allowable 
losses may be one sample per 60 seconds from each device. Therefore, at least 59 
samples per minute are be stored. These 59 samples must be perfect. 
1 0 False-positive network packets may occur where the packet is read incorrectly 

but the checksum happens to match so it is presumed to be correct. Reliability in this 
case is generally 99.99 %. 

A set of entry screens is provided to allow the input of bleed-related log 
information and maintenance log information, to be used after a period of downtime 
1 5 during which paper logging was used. Medium-resolution and high-resolution logs 
will not be reconstructed in the event of downtime; they will be considered 
expendable in this situation. 

Further, the system has the following compatibility requirements. Donor and 
bleed number barcodes that have been printed by another customer system in code 39 
20 or UCCEAN 1 28 formats, are readable by the system. Up to 20 alphanumeric 

characters are supported. If using UCCEAN 128, the facility must enter the barcode 
field identifiers for bleeds and donors in a setup function. 

Permanent donor number barcodes are generally 9 characters, e.g. A00001 888 
- where A00001 is a consecutive number (i.e. all the way thru Z99999) and 888 is a 3 
25 position unique facility number. 

Bleed number barcodes are generally ten characters, e.g. 00MMIAO0O1 - 
where 00 is the last 2 digits of the year, MMI is a unique facility identifier, and A0001 
is a consecutive number thru Z99999. 

Instrument barcodes that have been printed in UCCEAN 128 format, are be 
30 readable by the system. Instrument serial numbers allow up to 30 alphanumeric 
characters, and use field identifier 2 1 . 

Operator badge barcodes are printed by Baxter in UCCEAN 128 format and 
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are readabie by .he system. Badge numbers allow up to 15 alphanumeric characters, 

10, expiration date - format YYMML) 

Still further the database server should be accessible by wi y 
Still further, interfacin g with other existing or new systems, 

♦w tv«p facility can access data for interlacing wuu 

standard SQL accessible through, for example, Mtcrosoft ODBC and/or 
Thunder Microsoft Window, — 
method to allow the system to interface with Cher systems. Also, the securtty 
"•derations may limn the manner and level in which a facility can access the 



1 5 database 



^Instructions are be provided ,o enable a trained database administrator to 

be used to export data for review by regulatory agenc.es. 
„ L s stem provides a method for a donor management system to send a new 

0 «^*-^^-^— — 

ioht The system does not the use of donor and bleed 

25 losaed for that bleed. . nKtain 
The system also provides a way for a donor management system to obt^n 

summary data items for each bleed. The facility system also initiates ,H, transf r by 

yes/no (if no, then the summary data should no, be considered accural), arm used, 
30 dl Lion - yes or no, plasma volume collected, instrument number, over- or 
under-draw, and reason if so, cell loss volume, and donor number. 

The system server includes a mechanism for sending messages to a parttcular 
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instrument. ... 

The system also induces requirements for data transfer between the fac,Uty 
database and the HQ database. The facility database must be designed with a locatton 
identifier in each applicable record so tha, muKiple system databases can be merged 
without key violations (e.g. an ABRA 4-digit code). 

All management software functions and reports are available from the 
a PP ,ica,ion server a. the facility, and also from the application server at the fac.l.ty 
database. When running off of the HQ database, each function and report must 
reoues. user input to determine which location or region to affect. When runntng a, 
the facility, the functions do no, request such input. It is no. necessary for the operator 
logg mg functions, alarm/aler. tactions, or any other real-time functions to run agamst 

the facility database. . 

The system server is be backed up to the HQ server at intervals ass.gned by the 
facility, and only the changed records will be transferred. The backup includes the 
resolution logs (bleed-related data), the instrument-related data, maintenance-event 

data, and disposable lot data. 

The facility databases are polled every 15 minutes by HQ (or another user 
defined interval) and any changed records will be copied to HQ. Facility databases 
are, therefore, only temporary stores, and do not need any other backup scheme. 
HQ database may be backed up with a ape backup system or any other smtable 



20 

means. 



The provider has access to the high resolution procedure logs, ad-hoc one at a 
,ime This ,s accomplished by sending the logs automatically from the system server 
to the HQ server, and allowing the provider access to the area of the HQ server where 
25 ,ogs arc stored. The high-resolution logs may be copied during each nigh, from the 

facilities to HQ. , nnf u P 
Software upgrades are handled by action a. the HQ level only, and must no. be 

designed <o normally require center-level user interaction. 

The system and HQ servers typically run on Microsoft Windows NT 4.0 or 
30 later. The database servers typically run on Microsoft SQL Server 7.0 or later. 

DATA INTER FACING 

The present system relies upon data interfacing from three primary sources: the 
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accomplished via web browser technology. Therelore, 
several web pages for data input and verification. 

"-^^^^ 5,Sa, the screens for operating and monitoring the 
system ZTweb-based workstation are illustrated. These screens are negated very 

particular screen by simply clicking on a menu item. 

From anv screen any one of the following options may be selected, search 
From any screen, dny change the location 

(search by various criteria for bleed numbers), locatton (HQ on.y. change 

timeout which can be defined in setup). 

Referring ,o Pi g ure 5>e ,o 8 in screen OO is where , h e -r io^H 

asked to log in,o the system. If** « a, a fac.hty ISP, they™ 

facility da. on.y. .f they ate at headers, they can the 

Th e J JL *e password and dicks OK, then return. The system checks entr, 

The user em f welcome screen 92 (See 

aeainst the database. If there is a match, the system go 
25 againsiuicu ,, v ctem shows a message, e.g. 

tr » ^ if the user's credentials are incorrect, the system sno 
Figure 6). If the s >5 ^ ^ ^ system 

"Your ID or password is incorrect. Please try again. 

si;: Iher message, e.,»Vour,Dor password is incorrect. See your system 

30 ^r:— „ 92 ,i,,us,ra,edo„ F ignre 6 ,co m esu P w r a T er,o : 
into the system. If the user has logged into heado.uar.ers, they can choose to see a.1 
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location data from a pick list at the top of the screen. The pick list will drop down 
from the top with all data in one column, then all setup groups (from the setup screen, 
i.e. region 1, region 2, region 3, custom 1, by center), the "Center" option brings up a 
list on the right with all centers as options. Default will be all data. 
5 If a user has logged into a facility, the facility title will appear as a second 

heading and no location pick list will appear. 

From the welcome screen 92, the user can click any of the section tabs, 
"Search," "Administration," "Reports," "Monitor," "Dispatch," "Help,", or "Logout," 
to go to any section. 
10 Administration 

First, referring to Figures 7-26, the system 10 comprises a setup and an 
administration operation. The setup and administration operations are accessed by 
clicking on the "Administration" tab at the top of any screen. When the 
"Administration" tab is clicked, an administration menu 100 appears (See Figure 7). 
1 5 From the administration menu 1 00, information regarding facility operators, 

instruments, data, and the overall system can be input or edited. The information 
entered during setup is used during operation of the system 10 to verify operations, 
monitor procedures, monitor inventory, create reports, schedule maintenance, and the 
like. The administration menu 100 includes links to screens or pages where the 
20 information is inputted or edited. 

The administration menu 100 includes a link to a change password screen 101. 
As shown in Figure 8, the change password screen allows the user to change his/her 
password by simply typing their current password, their new password, and repeating 
their new password for verification. 
25 The administration menu 100 also includes a link to a reset passwords screen 

102, shown in Figure 9. To reset all user passwords, a timing for reset is entered on 
the screen, and the user passwords will reset accordingly. 

Another link on the administration menu 100 takes the user to an operator list 
page 104. Referring to Figure 10, the operator list page 104 comprises a list of the 
30 operators who work within the facility and links to other pages for adding new 

operators (see Figure 1 1), editing operator information (see Figure 12), deleting an 
operator (see Figure 13), and resetting an operator's password (see Figure 14). 
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Information regarding the operators qualifications to perform certain tasks or 
procedures or to use certain instruments is inputted by accessing the individual 
operator information page (Figure 12) from the operator list page 104. lo assign 
privileges to an operator for all the options within a category (e.g. web privileges, 
5 mobile privileges), the user clicks on "Check Group." The "Clear Group" button 
clears or deselects all the options within that category. 

Clicking on "Performance goals" on the administration menu 100 takes the 
user to a performance goals page 108. Referring to Figures 15 and 16, the 
performance goals page 108 comprises fields where goals for a specific time period of 

10 the facility's specific operations can be inputted. In the example illustrated, the time 
periods are for annual and monthly targets. The base information that is inputted into 
these fields can be compared against actual data generated as facility functions in its 
normal day-to-day operation. The performance goals page 108 further comprises links 
to pages that comprise the performance goals from the previous year and for the next 

15 year. 

Another link on the administration menu 100 takes the user to a product list 
page 112. The product list page 1 12 is illustrated in Figure 17 and comprises a list of 
the products/soft goods, disposable and otherwise, used during the facility's 
operations as well as links to pages for editing the product list (Figure 1 8) and the 

20 product components associated with each product (Figure 19). 

The administration menu 100 further comprises a link to an alarm/alert list 
page 116. As shown in Figure 20, the alarm/alert list page 116 includes information 
regarding alerts, alarms, or errors associated with the system's and facility's operations 
and further includes links to pages for editing alarm/alert list information (see Figure 

25 21). This page can be used to associate an alert/alarm with a level of severity and a 
particular cause, actions to be taken, and whether the alert should be reported. 
Referring to Figure 21, the "Action Level" field has 3 options. The "Severity" field 
determines the color in which the alarm/alert is displayed on screen. For example, the 
color can be gray, yellow, or red depending upon low to high severity. 

30 Another link on the administration menu 100 takes the user to a message list 

page 120. Referring to Figure 22, the message list page 120-comprises a list of the 
alerts/alarms. The actions taken in response to the alerts/alarms can be edited through 
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links for each alert/alarm listed (see Figure 23). Alternatively, default actions can be 
edited by via a default edit link. These messages can be displayed on the system 10 
when an alert/alarm is encountered in the system 10 and used in a pick list format. 
The administration menu 100 is also used to access policy page 124. As 
5 illustrated in Figures 24a and 24b, the policy page 124 allows the system 10 to be 
configured to expect a certain operations or procedural occurrences within the facility. 
For instance, the work schedule for the facility, production targets, exceptions, 
instrument timeouts, instrument service schedule, instrument calibration, types of 
barcodes expected, and other miscellaneous options can be inputted and stored. The 
1 0 system 1 0 eventually uses the data in setting system parameters or in a comparison to 
actual data collected during facility procedures. 

The administration menu also comprises a link to a recovery screen 126. The 
recovery screen 126 is illustrated in Figure 25. This screen is used to create bleed 
records or enter edits to existing bleed records with specific procedure information 
1 5 that was collected manually. Also, this function is used if the system 10 crashes and 
the facility procedure (e.g., an apheresis procedure) is continued. 

The administration menu 100 further comprises a link to an instrument list 
page 128. The instrument list page 128 is illustrated in Figure 26. It provides a list of 
instruments within the facility, an input portion to enable the instruments on the list, 
20 and links to pages 128a (Figure 27), 128b (Figure 28), and 128c (Figure 29) where 
instruments can be added, removed, and edited, respectively. 

Another link on the administration menu 100 takes the user to facility 
configuration page 130. This page, shown in Figure 30, is used to assign the 
instruments from the instrument list to a zone/bay/area within the facility. 
25 Yet another link on the administration menu 100 takes the user to a data 

logging options page 132. Referring to Figure 31, this page is used to tell the system 
10 how often to log data. For instance, the data logging page may comprise fields for 
high resolution diagnostic data logging interval, disk space reserve for high resolution 
logging, and the disk path for the high resolution logs. The data logging page may 
30 further comprise fields associated with medium resolution data logging options, such 
as when to save the medium resolution log data, e.g. on every key press of an 
instrument, on every alert, or after a specific duration of time. 
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The administration menu 100 also comprises a link to a network setup page 
136. As shown in Figure 32, the network setup page 136 is used assign the IP address 
to the system server 34 and any subnetworks. 

The administration menu 100 further comprises a link to a downtime page 140. 
5 As illustrated in Figure 33, the downtime page 140 is used to input the timing of a 
scheduled shutdown of the system 10. The shutdown can be for a variety of reasons, 
including maintenance, troubleshooting, software updating, and the like. A command 
may also be entered on this page to tell the system 10 to remain in the shutdown mode 
or to restart immediately. 

10 Finally, the administration menu 100 comprises a link to a statistic page 144. 

The statistic page 144, shown in Figure 34, includes a summary of the procedures 
performed within the facility. The statistic page 144 further includes fields for 
inputting the length of time to save data and whether the data should be deleted. For 
the system to accept information from these fields, the user must verify the 

1 5 information by inputting his/her valid password. 
Database Searching 

Next, referring to Figures 35 and 36, the system 10 comprises a search 
function. The search function is accessed by clicking on the "Search" tab at the top of 
any screen. When the "Search" tab is clicked, a search page 148 appears. Referring to 

20 Figure 35, the search screen 148 allows the user to find information pertaining to any 
bleed that is stored in the system database. The user can enter search criteria for as 
many fields as needed, click the "GO" button, and view the resulting records at the 
bottom of the screen. The search results can be sorted according to column headings 
by clicking the corresponding arrow. 

25 The search function allows the user to search for: a specific bleed number, a 

group of bleed numbers within a specific date range, all bleeds that occurred on a 
specific instrument (within a specific date range), all bleed numbers from one donor 
(within a specific date range), all bleeds that were performed by a specific operator 
(within a specific date range), and all bleeds that were performed with specific 

30 components or components from a specific lot (within a specific date range). 

To perform a search, the user enters any search criteria necessary and clicks the 
"GO" button. A Bleed List Report 150 (see Figure 36) sorted by bleed number is 
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Reporting function. The reporting 

(quality assurance). a user clicks on "Reports" from the options 

m enu to display the report menu screen*, ^ ^ 

se ,ect a report section tab and report type. The us. c ^ ^ 

action tah for the report he/she wishes c,Ls the appropriate 

displays. To select a different report in ma, secfon, 

being displayed is highlighted m whrte. ^ ^ Mos( 

If desired, the user can select a new „me frame to g ^ 

20 of selecting a timeframe, by clicking t 

^ '.n— n msonr « * - ^ a ^ ^ tnen the 

column in descendmg order. If . ^ sp , ayed sorted by 

re port is sor*b.e by that column vanab, - * _ ^ the ^ in 

25 the variable in the left-hand column. To re sort P 

th e heading of the column that he/she wishes to sort b y. ^ 

number, donor number, or other vanaHe *a s .sp ^ 
When the user clicks a link wtthm a report, a new 

30 provide great detail on a specific item withm ^ repor, ^ ^ ^ 
Now, referring to F.gures W^J 
statistics for all facility performance vanables. For 
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the actual value, the goal, and the difference between the actual value and the goal. 
The reports can be displayed as goal summaries and graphs, and as trend summaries 
and graphs. 

The goal tracking report 154 (see Figure 38) is used to compare target volumes 
5 collected with actual values collected for specific items on a day-to-date, week-to- 
date, month-to-date, or year-to-date basis. If a value is displayed in the "Difference" 
column, the value indicates that the goal for the selected item is larger or smaller than 
the actual count. 

The "Number of Procedures" field shows only the goals that have been entered 
10 in the system through the administration setup function. The "Yield Efficiency" field 
indicates the actual yield per target volume. The "Actualized Machine Utilization" 
field indicates procedures per machine, extrapolated to one year. 

The goal tracking graph 156, illustrated in Figure 39, is a graphic 
representation of the actual efficiency items compared to their goals on a day-to-date, 
1 5 week-to-date, month-to-date, or year-to-date basis. The default time frame for this 
report is week-to-date. The user can click on a graph to enlarge the report and click 
again to revert to summary format. 

Referring to Figure 40, the trend summary report 158 displays relative values 
for any entered data to help identify predictable trends. The default report range is 
20 week-to-date. The user may click on any variable to view a graphic image of the 
corresponding data on the right side of the screen. 

Figure 41 illustrates the trend graphs page 160. This report displays key 
indicators for any date range by week, month, day and year. The user may click on 
any graph to zoom in and click again to revert to summary format. The scroll bar 
25 allows the user to view additional graphs that do not fit on a single screen, screen. 

Referring to Figures 42-47, the staff reports are illustrated. The summary 
report 162, Figure 42, is only available to facility administrators. This report provides 
a summary of the relative rates of accuracy for the operators. The user may click on 
the arrows next to the column headings to change the sort order. 
30 Referring to Figures 43-45, the operator detail report is a detailed version of 

the data found in the summary report. It provides in depth operator details with an 
additional set of links. Operator detail reports can be viewed for machine setup, 
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procedure program, and arm prep venipuncture. 

Figure 43 illustrates the machine setup report 164. This report displays the 
operator detail for machine setup for a specified period. The user can click on the 
alerts link at the bottom of this screen to display details about the alerts. The accuracy 
5 field indicates the accuracy percentage on the operator's first try. The number of 

setups field indicates the number of machine setup events logged by the operator. The 
number of passes on 1 st try field indicates the number of machine setups that had no 
associated alarms/alerts. This number is used to calculate the accuracy percentage. 
The number of passes on 2 nd try field indicates the number of machine setups that had 
10 just one associated alarm/alert. The number of passes on 3 rd try field indicates the 
number of machine setups that had exactly two associated alarms/alerts. The number 
failed field indicates the total number of machine setups less the setups that had 
exactly two associated alarms/alerts. 

The procedure program report 166 is illustrated in Figure 44. This report 
1 5 displays the operator detail for procedure program for a specified period. The 
accuracy field is displayed as a percentage based on the frequency of setups that 
resulted in alarms/alerts. The number of procedure setups field indicates the number 
of machine setup events logged by the operator. The plasma nomogram checks field 
indicates the number of times that there was a mismatch between expected and 
20 programmed plasma volume. The percentage field is derived from the total counts per 
completed setup. The bleed number list field displays the bleed numbers that were 
included in the count of nomogram checks. 

The arm prep/venipuncture report 168 is shown in Figure 45. This report 
provides an overview of the arm preparation and venipuncture for each operator. The 
25 user clicks on the alerts link at the bottom of this screen to display details about the 
alerts. The VP frequency field indicates the frequency of venipuncture alarms/alerts 
associated with the operator. The total venipunctures field indicates the number of 
venipunctures logged by the operator. 

The operator alarm/alert reports are illustrated in Figures 46-48. This report 
30 provides an overview of the alarm/alert details and can be viewed for operator 

summary, operator detail, and alarm/alert summary- The reports can be viewed in 
normalized or raw data mode by clicking on the toggle switch on this screen. The 
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values in the report that appear in black color indicate actual raw data and the numbers 
that appear in red are the normalized data per 1000 procedures. The normalized data 
is used as a form of comparison to determine the averages. 

Referring to Figure 46, the alarm/alert summary report 170 is illustrated. This 
report displays all of the alarms/alerts across the screen. All of the instruments where 
the alarm/alert occurred are listed down the screen. All of the operators associated 
with the alarms/alerts are also listed down the screen. The instrument numbers and 
operator IDs listed in this report link to the alarm/alert detail report (Figures 47 and 
48) that lists the associated bleed numbers. 

The alarm/alert detail report 172, 174 is shown in Figures 47 and 48. This 
report provides details of the alarm/alert by instrument or by operator depending upon 
the selection made in the alarm/alert summary report 170 (Figure 46). The user may 
also access this screen by clicking the links from the operator summary report 162 
(Figure 42) or the instrument summary report (Figure 60). This report is typically 
used by supervisors to identify the areas in which operators may need training. The 
bleed numbers listed on this report may be used to link to the bleed detail report 
(Figures 52-55) . 

The donor reports are illustrated in Figures 49-55. All reports related to 
donors and bleeds are available in the donor reports. Reports can be generated about 
specific donor histories and donor reactions, specific bleeds (summary and details), 
and bleed information over a specific time frame or a range of bleeds. The user enters 
a valid donor number at the "Donor #" field to begin generating these reports. 

Referring to Figure 50, the donor history report 180 is illustrated. This report 
provides a summary listing of all bleeds for a single donor in chronological order. To 
view full details about a bleed, the user clicks on the bleed number. Also, if any 
alarms/alerts are displayed for the bleed, the user may click on the alarm/alert link to 
display a list of bleed numbers that had that an alarm/alert. This report also has a link 
to the bleed details report (Figures 52-55). 

Next, Figure 51 shows the donor reaction report 182. This report provides 
details about all donor reactions that occurred during a specific time frame in 
chronological order. To view donor histories, the user clicks on the donor number. To 
access bleed details, the user clicks on the bleed number. 
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,n Figures 52-55, the various bleed detail reports are shown. The bleed detail 
reports include maehine setup reports, procedure reports, exception reports, and Ml 

detail reports. 

The machine setup report 184 is illustrated in Figure 52. This report „ a 
5 summary of donor and bleed details for machine setup. This report lists the products 
used during the bleed and displays any alerts/alarms that occurred during the setup^ 
The user may dick on the operator ID to view the operator details report (Figures 44- 

48) 

Referring to Figure 53, the procedure report 186 is a summary of donor and 
10 bleed details for the procedure setup obtained from the logging records. 

Figure 54 is an illustration of the exceptions report 188. This report displays 
all of the exception resolutions logged during the bleed, except for those displayed 

under the machine setup report. 

Figure 55 shows the full detail report 190. This report provides a med.um 
,5 resdution tog of instrument variables in chronological order. It includes a log of 
operator-initiated even,, The report shows the date, time, and a description of the 

event that was logged. 

The inventory reports are illustrated in Figures 56-59. The inventory reports 
allow the user to track information related to products used in the center and search 
20 and sort by product and lot number. The inventory reports include the followtng 

reports: inventory usage, performance by product, performance by lot, rep.entshment. 

The inventory usage report 192 is illustrated in Figure 56. This is a summary 
report that lists the product numbers used in any bleed fo, a specifed period. The user 
may click on the product number ,0 see details for tha, product. The default time frame 
25 for this report is month-to-date. When this report is generated from a regional or 
higher level (central server), the report includes an additional button for disposab.e 
reordering. 

The performance by product report 194 is shown in Figure 57. Th,s is a 
summary report listing all of the lot numbers found for the selected product and used 
30 within the specified time frame. 

Referring to Figure 58, the performance by lot report 196 is illustrated. This ,s 
a detailed report that provides information of disposables by lot number. 
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default time frame for this report is month-.o-da«e 

summary and detailed statistics for the — , s^h * mfc ^ ^ 

procedures performed on a machine, mamtenance and serving 
alarm/alert summary report. This is a 

Referring to Figure 60, the instrument summary ^ ^ 

summary report with information about the run hours for each tnstnnn 
ITIirlmen , - ^r can ciic. on me ins^en— ^ 

The instrument detail reports are — reports include 

the maintenance, service, alarm/alert, and tu ^ fr ^ 

from a facility, on.y data from that facihty - dtsp.ayed. .f rep 
5 a headquarters, a complete history may be viewed. 

Firs,, referring to Figure 61, the instrument mamten^ . 

-.nustrated. T^«-~~r^££E-. —the 

Further, Figure 64 is an illustrate of the mstrum 

,08 The report lists alerts and alarms produced by an tnstrum n, The user 
208. The repo ^ number hnk 

25 the bleed details (Figures 52-55) by chck.ng ^ 
Figure 65 is an illustration of the instrument full detail repo 
,U.s details about all actions performed on an instrutnen ,. 

Finally Figure 66 is an illustration of the mstrumen, out of serv P 
finally, r B -mice and the details related to these 
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q/A exception reports, the open system message report and the proee 

supervisor to identify all open alarms To dear P ^ ^ 

even, on a mobile deviee (see below) or under setup. The 

details from this report. This report lists 

i an exception is determined by the faculty an 

system setup function (see above). There are three types of Q/A review 

Figures 69 . 70 are the Q, A review reports The, - J 
reports, the bleed number review, instrument review, and the all 

report ' . * ^-, 18 This reoort is usually used by 

c - .^Qka O/A bleed details report 218. 1 rus repoi 
> 0 Figure 69 is a (^/a oiec rev iewed. The user 

• to nuerv records by bleed number and mark them as review 
supervisors to query records y fl , ia to acceS s the bleed details. To review 

enters a bleed number in the bleed number field to access t 

and clicks on "Update." 

«rtT>n The user enters an instrument 
Fieure 70 is the instrument review report 220. Iheuse 

u rv,„rV them as rev ewed, or edit them isee r igu / 
by instrument number, mark them as re orri , reD ort 222 This report 

Fig ure 71 is an illustration of the all reviewed reco s report 2 
is USU ally used by supervisors to query all reviewed records. Tb^i 
30 this screen link to the bleed details report. The instrument numbers 

to the instrument details report. Figure 72 is 

Figures 72 and 73 show the Q/A corporate quarantine lots reports 
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a view the disposable/soft good lots on quarantine report 224. This report is usually 
used by supervisors to query lots on quarantine. Figure 73 is the put lot on quarantine 
report 226. This report can only be used from HQ and is used to place a lot on 
quarantine. 

Figures 74 and 75 are the Q/A release incoming disposables reports. Figure 74 
is a view released lots report 226. The supervisors use this report to view a list of 
products that have been released for use. Figure 75 is the release incoming 
disposables report 228. This report allows facility supervisors to release incoming 
products for use. 

Finally, Figure 76 is an illustration of the Q/A modify records report 230. The 
supervisors use this report to modify log entries in a record. The user enters a bleed 
number or an instrument number to modify its record. The user must enter their user 
ID and password for the changes to take effect. 
Instrument Monitor 

Referring to Figure 77, the monitoring page 232 is accessed by clicking on the 
"Monitor" tab. The monitoring screens 232 provide information on the current state 
of the machines in the center. The screens show all of the instruments arranged by 
area/bay within the facility. Each instrument is represented on screen by a bar. It may 
be necessary to scroll down or to the right to view all of the instruments in the facility. 
Figure 77a shows potential information that is available for each instrument. 
Instrument Dispatch 

The instrument dispatch screen 236 is illustrated in Figure 78. The dispatch 
screen 236 is used to monitor the activities in the donor facility: It may be used in the 
following situations: to dispatch donors to the donation floor; help control work flow 
in the facility; or provide a quick view of the donor floor. To access the dispatch 
function, the user clicks "Dispatch" from the options menu. Figure 78a shows 
potential information that is available on the dispatch screen. 
Wireless Interfacing 

Figures 79-105 illustrate the various screens associated with the wireless 
interfaces or PDAs. The wireless interfaces are used by the facility operators to 
interface with the other components of the system. Each wireless interface includes 
buttons, data entry fields, pick lists, login and logout formats, and multiple input and 
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output screens. 

A button is defined as a visual graphic accessed either by a mouse-click or by 

Tab-Enter/Return. All buttons produce an audible click, and have up, down and 

disabled states. The up state is the resting state. When a button is down-clicked, the 
5 down state appears. When the button is released (the up-click), the button event is 

processed. Note that when an overlay appears on the screen, underlying buttons are 

temporarily disabled. 

Every data entry field has an active state and an inactive state. Active fields 

appear brighter than inactive fields. Data input screens come up with the first field 
1 0 active. Only one data entry field is active at a time. An active highlight can be moved 

to a new field by pressing Enter/Return or Tab, or by clicking the mouse on another 

field. 

Pick lists are offered whenever possible. Pick list entries have an arrow on the 
right side of the field. When that arrow is clicked, the entire pick list appears with a 
1 5 highlight on its first item. If a pick list is to long to fit onscreen in a single column, it 
is scrollable. A pick list appears right-justified to the data entry field, and its highlight 
moves with the cursor up and down the list. 

Users can login to a specific URL for each facility or for the headquarters. 
Once at the site they will be asked for their ID and password to access the database. 
20 Users can also log out by pressing "Logout" on the menu. After logging out, the 
interface returns to the login screen. 

Each wireless interface screen is described with reference to a Figure, and an 
itemization of the objects on screen and their individual functions. However, the 
actual screens will be high-quality graphic images, whose placement of elements may 
25 differ from that of the Figures. 

Referring to Figure 79, a login screen is used to log an operator onto a 
particular palm device. The user scans his/her bar coded ID and presses OK. If the 
user has used device within several hours (definable variable), the device goes directly 
to a main menu (but goes to alerts if there are any active alerts). If not, the device goes 
30 to a password screen. If the user had previously pressed "Logout" to log out, then the 
device goes to the password screen. If the user ID does not match fields in the 
database, the device shows an error message such as "Your badge is unrecognized, 
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please try again"; then allows the user to try again. 

Referring to Figure 80, a password screen is used to validate the user's 
password. The user enters his/her password. The system verifies the user ID and 
password against the database and checks that these match the previously scanned 
5 barcode. If there is a match, the device proceeds to an assign machines screen (Figure 
81). If the user ID and password do not match fields in the database, an error message 
is displayed, and the user is returned to the login screen. 

The assign machines screen, Figure 81, is used to assign one or more 
instruments to a particular operator. Once the assignment is made, alarms/alerts from 
10 that instrument may be associated with the operator, for the duration of that operator's 
shift. The user scans any number of instruments, or the user presses "Watch All 
Machines" to associate himself/herself with all of the instruments in the facility. 

A number of machines scanned so far field displays the number of distinct 
machines that have been scanned while on this screen. If the user scans an instrument 
1 5 machine, the device adds the machine to the association list, increments the "Number 
scanned so far" field, and redisplays the same page. If the user clicks "Start over," the 
device clears the associations and redisplays the page. If the user clicks "Watch All 
Machines," the device associates all enabled instruments with the operator and goes to 
the main menu. If the user click "Done," the device goes to the main menu (Figures 
20 82a and 82b) (Note: this can be done even if no machines have been scanned). 

The main menu allows the user to select a function. This screen appears if a 
user has just logged on, or completed a prior action. The main menu is the primary 
screen in executing any logging sequence. At the end of the various routines, the 
system automatically returns to this screen. 
25 The routines available through the main menu are categorized into the 

following four groups which appear as tabs on the upper portion of the screen and as 
headings as the user scrolls down the main menu: Standard Procedure; Exceptions; 
Maintenance; and Commands. The user can use the four tabs on the main menu to 
jump to that menu item. The items associated with that menu tab are then displayed. 
30 Alternatively, the user may scroll down the display window to view all the options. 

Referring to Figures 82a and 82b, if the user clicks "Alert," the device goes to 
an "Alert" screen. If the user clicks "Logout," the device goes to the login screen, and 
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clears the association of machines from the operator. 

Under the Commands group, if the user clicks "Check Current Bleed Log," the 
device goes to a show log screen (Figures 83a-83b); if the user clicks "Check Machine 
Assignments," the device goes to a check machine assignments screen (Figure 84); if 
5 the user clicks "Display" the device goes to a check text screen (Figures 85a-85b); 
and if the user clicks "Logout," the device goes to the logout screen (Figure 86). 

Under the Standard Procedure group, if the user clicks "Machine Setup," the 
device goes to a machine setup logging screen (Figures 87a-87c); if the user clicks 
"Procedure Program," the device goes to a procedure program screen (Figures 88a- 

1 0 88e); if the user clicks "Arm Prep," the device goes to the an arm prep screen (Figures 
89a-89d); if the user clicks "Venipuncture," the device goes to a venipuncture screen 
(Figures 90a-90d); if the user clicks "Remove Plasma," the device goes to a remove 
plasma screen (Figures 91a-91e); and if the user clicks "Disconnect donor," the device 
goes to a disconnect donor screen (Figures 92a-92c). 

1 5 Under the Exceptions group, if the user clicks "Manual Saline," the device 

goes to a manual saline screen (Figures 93a-93d); if the user clicks "Donor Reaction," 
the device goes to a donor reaction screen (Figures 94a-94c); if the user clicks 
"Resync," the device goes to a resync screen (Figures 95a-95c); if the user clicks 
"Move Donor to different Machine," the device goes to a move donor screen (Figures 

20 96a-96i); if the user clicks "Procedure Termination," the device goes to a procedure 
termination screen (Figures 97a-97f); if the user clicks "Other Log Entry," the device 
goes to an other log entry screen (Figures 98a-98c); if the user clicks "Change Kit 
Component," the device goes to a discard product submenu, page 1 (Figures 99a-99o); 
and if the user clicks "Product Performance," the device goes to a discard product 

25 submenu, page 2 (Figures 99b-99o). 

Under the Maintenance group, if the user clicks "Daily Maintenance," the 
device goes to a daily maintenance screen (Figures lOOa-lOOf); if the user clicks 
"Weekly Maintenance," the device goes to a weekly maintenance screen (Figures 
101 a- 1 01 h); if the user clicks "Monthly Maintenance," the device goes to a monthly 

30 maintenance screen (Figures 102a-102h); if the user clicks "Field Service," the device 
goes to a field service screen (Figures 103a-103d); if the user clicks "Out of Service," 
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the device goes to an out of service screen (Figures 104a- 104c); if the user clicks 
"Back in Service," the device goes to a back in service screen (Figure 105a-105f). 

Now referring to Figures 82a-82h, the "ALERT" button is highlighted, and an 
alarm/alert log is displayed at the top of the screen (as shown in Figure 82b) when 
5 there are active alarm/alerts for the operator. Alarms and alerts are errors, warnings, 
or notices on any instrument assigned to a user or generated by the system server. 
When the user selects "More" on this screen, Figure 82d is displayed. The difference 
between Figures 82c and 82d is that the operator associated with the screen of Figure 
82c had no active alarm/alert messages whereas the operator associated with the 
1 0 screen of Figure 82d had several active alarm/alert messages. 

The user can resolve alarms and alerts by clicking on any of the listed 
messages, The details about the selected alarm/alert is then displayed as shown in 
Figure 82e. The alarms/alerts are listed in reverse chronological order based on when 
the user last visited each instrument. 
1 5 To view a list of all alarms/alerts for a given instrument, the user scans the 

instrument's barcode while the alarm/alert log screen (Figure 82c or 82d) is displayed. 
The current log is replaced with a list of active alarms/alerts for that machine. To 
clear an alarm or alert, the user can: select it from the alarm/alert list on the main 
menu screen, or select it from the alarm/alert log. 
20 When the user clicks on an alarm/alert, if the alarm/alert requires a log 

response, the device goes to the appropriate logging screen to log the resolution to this 
alarm/alert, and then clears the alarm/alert after a log is committed. The log screen 
that is displayed depends upon the type of alarm/alert. If the alarm/alert does not 
require any response, the device displays Figure 82b. When the user scans a machine, 
25 the device replaces the list of alarm/alerts with the list of active alarm/alerts associated 
with the instrument. When the user clicks "OK," the device clears the alarm/alert and 
returns to the screen of Figure 82a. However, if the user is not authorized to clear this 
alarm/alert, the device asks for a supervisor ID scan for validation. When the user 
clicks "Cancel," the device goes to the screen of Figure 82a. 
30 Figures 83a-85 illustrate the screens under the Command group. First, 

referring to Figures 83a and 83b, the check log screens are displayed. The check log 
screen shows what has already been logged in connection with a particular instrument. 
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The operator can view this log to determine whether he/she has forgotten to log an 
event. 

The user scans the instrument to view all log entries made for the bleed in 
progress on that instrument. The bleed is determined by the bleed in progress. If no 
5 bleed is in progress, no information is displayed. Each log entry is listed first by name 
with no detail, then all of the entries are listed again with full detail. Clicking on the 
summary entry will scroll the display to the corresponding detail entry. 

When the user scans an instrument, if the instrument has a bleed in progress, 
the device displays the screen of Figure 83b; otherwise, the device shows an error 
10 message. If the user clicks on a summary entry (e.g. machine setup), the device scrolls 
down to the corresponding detail entry. If the user clicks "Done," the device goes to 
the main menu. If the user clicks "Cancel," (also denoted in the Figures as an "X") the 
device goes to the main menu. 

Figures 84 is an illustration of the check machine assignments screen. This 
1 5 screen is used to check which instruments are assigned to a particular operator. Thus, 
this screen allows the operator to view a list of the instruments. The machine list field 
displays all of the instrument numbers (both low number and serial numbers) 
associated with the operator. If the user clicks "Change," the device goes to the assign 
machines screen (see Figure 81). If the user clicks "Done," the device goes to the 
20 main menu. 

The get text screen (Figures 85a and 85b) helps troubleshoot network or setup 
problems by testing the communication path from the scanner to the instrument. The 
user scans an instrument, which causes the instrument's display to show up on the 
PDA as shown on Figure 85b. When the clicks "Done" or "Cancel," the device goes 
25 to the main menu. 

The remaining screens are event logging screens. The event logging screens 
are used to log operator actions on the system, e.g. a machine setup, a venipuncture, 
and so on. All screens contain a top banner displaying the event type. The main part 
of the screen varies depending on the event type. Many of the events require a series 
30 of screens to enter all of the information to log. 

If the screen is in a series (except the first), it includes a "Previous" (or back 
arrow) button and a "Next" (or forward arrow) button, which goes to the previous 
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screen or next screen in the series. If the screen is a single-screen entry or is the last in 
the series, it includes a "Verify/Scan badge" entry field, which, when filled with the 
correct user ID for the current user, logs/verifies the event. The "Cancel" (or "X") 
button takes the user back to the main menu without logging anything. 
5 Log entries require scanning the operator badge to commit/verify. For each 

attempted log entry, the system matches the scanned badge ID with the ID that was 
used when the operator logged in initially. If there is a match, the log entry is 
committed, and the subsequent action is taken (usually to return to the main menu). If 
it does not match, an error is presented, such as "You did not scan the correct operator 

1 0 badge," and the user returns to the main menu without logging anything. This prevents 
accidental swapping of devices between operators. If this occurs, the operator will 
have to start over with the log entry. 

Figures 87-92 are related to the Standard Procedure group. First, Figures 87a- 
87c represent the machine setup screen. The machine setup screen is used for the 

1 5 original instrument setup as well as for replacement products. When called as a 

subroutine in the latter case, the title is "Replacement Product." The machine setup 
screen is where the user enters the data necessary for a machine setup log entry. Up to 
10 product components can be entered, and the screen of Figure 87b is presented 
multiple times as necessary. The scan machine field comprises the scanned instrument^ 

20 ID. The unlabeled scan fields comprise one to three barcode scans including the 

product code, lot number, and expiration date. These are shown as scanned on screen 
and unpacked into the components when saved and shown in Figure 87c. When the 
user scans a machine, the device displays the screen of Figure 87b. When the user 
clicks "NEXT" or "More Products," the device repeats the screen of Figure 87b for 

25 another component. When the user clicks "Done," the device shows the screen of 
Figure 87c. When the user clicks "Re-scan," the device deletes the component and 
returns to Figure 87b to allow the operator to re-scan the component. The operator 
may simply press "DONE" again to remove the component without replacing it with a 
new one. When the user scans the correct operator ID, the device commits the log 

30 entry and goes to the main menu. 

The procedure program screen is illustrated in Figures 88a-88e. The procedure 
program screen is where the user enters the data necessary for a procedure-program 
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bleed that was scanned for the procedure-program log entry on the same machine) and 
displays an error message if not. If OK, the device goes to page 3 (Figure 90c). If the 
user scans the correct operator ID, the device logs the entries. If a blood sample is 
needed, the device goes to page 4 (Figure 90d). Else, the device goes to the main 



menu. 



The user enters data necessary for a remove plasma log entry on the remove 
plasma screen (Figures 91a-91e). If this screen is accessed from the main menu, page 
1 (Figure 91a) is shown first. If the screen is accessed from the alert screen, page 2 
(Figure 91b) is shown first (since the machine is already known based on the alert). 
1 0 Page 3 (Figure 9 1 c) is only shown if the system detects an over or under-draw (UON 
or UUN). 

The calculated nomogram is displayed in the calculated nomogram field. This 
is the value passed from the facility system. The actual collection field is an entry 
field. The default value displayed in the field is the value calculated by the 
1 5 instrument. The user can override this. The reason for over/under-draw field is a pick 
list field which contains user defined reasons. 

If the user scans the instrument, the device checks whether there is a remove 
plasma alert active for that instrument. If there is no active alert, the device goes to 
page 2 (Figure 91b). If there is an active alert, the device gives an error message. If 
20 the user clicks "OK" (Figure 9 1 c) the device calculates whether the default or 

corrected actual volume constitutes a UUN/UON. If so, the device goes to page 4 
(Figure 91d). Else, the device goes to page 5 (Figure 91e). If the user clicks a reason 
from page 4 (figure 91d), the device goes to page 5 (Figure 91e). If the user scans the 
correct operator ID, the device logs the entries and goes to the main menu. 
25 The user enters data necessary for a disconnect donor log entry on the 

disconnect donor screen (Figures 92a-92c). If this screen is accessed from the main 
menu, page 1 is shown first. If the screen is accessed from the alert screen, page 2 
(Figure 92b) is shown first (since the machine is already known based on the alert). 
If the user scans the instrument, the device checks whether there is a 
30 procedure-end alert active for that instrument. If there is no active alert, the device 
goes to page 2 (Figure 92b). Otherwise, the device shows error message. If the user 
clicks "Yes" or "No," the device goes to page 3 (Figure 92c). If the user scans the 
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correct operator ID, the device logs the entries and goes to the main menu. 

The screens of the Exceptions group are illustrated in Figures 93-99. First, the 
manual saline screen comprises the data necessary for a manual saline log entry 
(Figures 93a-93d). The reason and outcome fields are a pick list fields. The notes 
field is a free-form entry field. 

If the user scans the instrument, the device goes to page 2 (Figure 93b). If the 
user selects a reason, the device goes to page 3 (Figure 93c). If the user selects an 
outcome, the device goes to page 4 (Figure 93d). If user scans the correct operator ID, 
the device logs the entries and displays the main menu. 

The donor reaction screen (Figures 94a-94c) comprises the data necessary to 
produce a donor reaction log entry. This log type requires the entry of a bleed number 
instead of an instrument ID due to the possibility that the reaction occurred after the 
donor left the instrument, and the instrument may be in use with another donor. The 
scan bleed field comprises the scanned bleed number. The outcome field is a pick list 
field. The notes field is a free-form entry field. 

If the user scans the bleed number, or manually enters it, the device displays 
page 2 (Figure 94b). If the user clicks an outcome, the device displays page 3 (Figure 
94c). If user scans the correct operator ID, the device logs the entries and goes to the 
main menu. 

The reboot-resync screen (Figures 95a-95c) allows the user to enter the data 
necessary for a reboot-resync log entry, which is required only in failure cases when 
the system server is rebooted while a donation is in progress. However, the instrument 
is identified by the system and does not have to be scanned because this log entry is 
made in response to an alert that is based on the machine. The scan bleed field 
comprises the scanned bleed number, and the scan donor comprises the scanned donor 
ID. 

If the user scans the bleed number, the device advances to page 2 (Figure 95b). 
If the user scans the donor number, the device advances to page 3 (Figure 95c). If user 
scans the correct operator ID, the device logs the entries and goes to the main menu. 

The move to a different machine screen (Figures 96a-96i) provides the means 
for the user to enter the data necessary for a move-donor log entry. The reason and 
outcome fields are facility definable pick list fields. The plasma volume and notes 
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field are entry fields. 

When the user scans the instrument, the device goes to page 2 (Figure 96b). 
When the user scans the bleed number, the device goes to page 3 (Figure 96c). When 
the user scans the donor ID, the device goes to page 4 (Figure 96d). When the user 
selects a reason, the device goes to page 5 (Figure 96e). If the collection container was 
transferred to a new machine, the user selects "Yes," and page 6 (Figure 96f) is 
displayed. If the collection container was not transferred to the new machine, the user 
selects "No," and page 7 (Figure 96g) is displayed. 

If page 6 (Figure 96f) is displayed, the user enters the volume of plasma 
collected before moving the donor. The user then selects "Next," and page 7 (Figure 
96g) is displayed. When the user selects an outcome, the device goes to page 8 
(Figure 96h). If user scans the correct operator ID, the device logs the entries and goes 
to page 9 (Figure 96i). If the user wishes to log a product performance issue, he/she 
selects "Yes" on page 9 (Figure 96i), the product performance issue routine (described 
below) is displayed. If the user does not wish to log a product performance issue, 
he/she selects "No", and the main menu is displayed. 

The procedure termination screen allows the user to enter the data necessary 
for a procedure-termination log entry (Figures 97a-97f). This is used for an abnormal 
disconnect, not for a successful completion. The reason field is a facility-definable 
pick list field. The cell loss volume field is a numeric entry field. The default value 
displayed is calculated from instrument data. 

When the user scans an instrument, the device goes to page 2 (Figure 97b). 
When the user selects a reason, the device goes to page 3 (Figure 97c). If the user 
clicks "Yes" or "No" on page 3, the device goes to page 4 (Figure 97d). If the user 
clicks "Yes" or "No" on page 4, the device goes to page 5 (Figure 97e). The cell loss 
volume as calculated by the machine is displayed on page 5, if available. If this 
volume is incorrect or if no cell loss volume is displayed, the user enters the volume 
manually. If the user clicks "Next" on page 5, the device goes to page 6 (Figure 97f). 
If the user scans the correct operator ID, the device logs the entries and goes to the 
main menu. 

The other log entry screen (Figures 98a-98c) allows the user to enter the data 
necessary for a miscellaneous log entry. This would be used for unusual occurrences 
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for which no log entry type was defined. 

If the user scans the instrument or clicks "Skip Machine," the device displays 
page 2 (Figure 98b) . If the user scans the bleed number or clicks "Skip Bleed," the 
device displays page 3 (Figure 98c). If user scans the correct operator ID, the device 
5 logs the entries and goes to the main menu. 

Referring to Figures 99a-99o, the screens associated with a discarded product 
(disposables/soft goods) log entry are illustrated. Because the scenarios that occur 
when products are discarded are especially complex, they are broken out into sub- 
menus and several subroutines. The required data items that must be stored with each 
10 of the three kinds of log entries used within the change-kit scenarios are product 
performance (records when any product is discarded for any reason), second 
venipuncture (records when a second stick is made for any reason), and machine setup 
(records when a new product is used for any reason). 

If the user selects the "Change Disposable Component" button under 
1 5 Exceptions from the main menu, the change disposable screen is activated. When the 
user clicks the "Change Disposable Component" button, page 1 (Figure 99a) is 
displayed. Upon selecting any of the three logging options on page 1, page 2 (Figure 
99b) is displayed. Depending on the logging option selected on page 1 (Figure 99a), 
the specific screens that the device displays will vary depending on the reason for the 
20 change and when the change occurred (from page 2), the reason for the discard, 

performance issue, second venipuncture, or other. If the disposable is discard for a 
performance issue, there are three types of information to log: the reason for the 
change; information about the component being discarded; and information about the 

replacement component. 
25 If the disposable is changed for a performance issue prior to the bleed 

procedure, the following procedure is followed. The user selects "Performance Issue- 
on page 1 (Figure 99a), and page 2 (Figure 99b) is displayed. The user selects "Before 
Use" on page 2, and page 3 (Figure 99c) is displayed. The user scans the instrument's 
barcode, and page 4 (Figure 99d) is displayed. A discarded product category is 
30 selected from a pick list on page 4, and page 5 (Figure 99e) is displayed. Once the 
user has selected a discarded product code from the list provided on page 5, page 6 
(Figure 99f) is displayed. On page 6, the user either selects the lot number of the 
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discarded product or enters the lot number manually. After the lot number is entered, 
page 7 (Figure 99g) is displayed. On page 7, the user selects the problem that 
occurred with the disposable product, and page 8 (Figure 99h) is displayed. On page 
8, the user selects the component that the problem occurred with from the list 
provided. If the problem occurred with a separation device, then page 10 (Figure 99j) 
is displayed. Otherwise, page 9 (Figure 99i) is displayed. 

On page 10, the user enters the videojet number in the spaced provided and 
selects "OK." Page 9 (Figure 99i) is then displayed. 

On page 9, the user verifies the information that is displayed and uses the 
space provided to enter additional notes about the discarded component. The 
information is verified and committed to the system when the user scans his/her ID 
badge. The main menu is then displayed. 

In a second scenario, the disposable product is discarded for a performance 
issue after the bleed has begun. In this scenario, the user selects "Performance Issue" 
from page 1 (Figure 99a), page 2 (Figure 99b) is displayed. On page 2, the user selects 
when the products was changed (other than "Before Use"), page 3 (Figure 99c) is 
displayed. On page 3, the user scans the instrument's barcode number, and page 4 
(Figure 99d) is displayed. A discarded product category is selected from a pick list on 
page 4, and page 5 (Figure 99e) is displayed. Once the user has selected a discarded 
product code from the list provided on page 5, page 6 (Figure 99f) is displayed. On 
page 6, the user either selects the lot number of the discarded product or enters the lot 
number manually. After the lot number is entered, page 7 (Figure 99g) is displayed. 
On page 7, the user selects the problem that occurred with the disposable product, and 
page 8 (Figure 99h) is displayed. On page 8, the user selects the component that the 
problem occurred with from the list provided. If the problem occurred with a 
separation device, then page 10 (Figure 99j) is displayed. Otherwise, page 9 (Figure 
99i) is displayed. 

On page 10, the user enters the videojet number in the spaced provided and 
selects "OK." Page 9 (Figure 99i) is then displayed. 

On page 9, the user verifies the information that is displayed and uses the 
space provided to enter additional notes about the discarded component. The 
information is verified and committed to the system when the user scans his/her ID 
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badge, and page 15 (Figure 99o) is displayed. On page 15, if a component was 
replaced, the user selects "Yes," and page 14 (Figure 99n) is displayed. On page 14, 
the user scans the barcodes for the replaced component, selects "Done," and the main 
menu is displayed. If the component was not replaced, the user selects "No," and the 
5 main menu is displayed. 

In the next scenario, the user selects "Second Venipuncture" from page 1 
(Figure 99a), and page 3 (Figure 99c) is displayed. On page 3, the user scans the 
instrument's barcode number, and page 4 (Figure 99d) is displayed. A discarded 
product category is selected from a pick list on page 4, and page 5 (Figure 99e) is 

10 displayed. Once the user has selected a discarded product code from the list provided 
on page 5, page 6 (Figure 99f) is displayed. On page 6, the user either selects the lot 
number of the discarded product or enters the lot number manually. Once the lot 
number is entered, page 1 1 (Figure 99k) is displayed. The reason for changing the 
component is selected from the list provided on page 11, and page 12 (Figure 991) is 

1 5 displayed. The outcome of the second venipuncture is selected from the list provided 
on page 12, and page 13 (Figure 99m) is displayed. The user verifies the information 
displayed and uses the space provided to enter additional notes about the discarded 
component. The user scans his/her ID badge to commit/verify the information, and 
page 15 (Figure 99o) is displayed. On page 15, if a component was replaced, the user 

20 selects "Yes," and page 14 (Figure 99n) is displayed. On page 14, the user scans the 
barcodes for the replaced component, selects "Done," and the main menu is displayed. 
If the component was not replaced, the user selects "No," and the main menu is 
displayed. 

The final scenario is when a product is changed for any other reason. Here, the 
25 user selects "Other" from page 1 (Figure 99a), and page 3 is displayed. On page 3, the 
user scans the instrument's barcode number, and page 4 (Figure 99d) is displayed. A 
discarded product category is selected from a pick list on page 4, and page 5 (Figure 
99e) is displayed. Once the user has selected a discarded product code from the list 
provided on page 5, page 6 (Figure 99f) is displayed. On page 6, the user either 
30 selects the lot number of the discarded product or enters the lot number manually. 
Once the lot number is entered, page 1 1 (Figure 99k) is displayed. The reason for 
changing the component is selected from the list provided on page 1 1 , and page 1 3 
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(Figure 99m) is displayed. The user verifies the information displayed and uses the 
space provided to enter additional notes about the discarded component. Next, the 
user scans his/her ID badge to commit/verify the information, and page 15 (Figure 
99o) is displayed. On page 15, if a component was replaced, the user selects "Yes," 
5 and page 14 (Figure 99n) is displayed. On page 14, the user scans the barcodes for the 
replaced component, selects "Done," and the main menu is displayed. If the 
component was not replaced, the user selects "No," and the main menu is displayed. 

The screens of the Maintenance group are shown in Figures 100-105. First, 
the daily maintenance screen (Figures lOOa-lOOf) is where the user enters the data 

10 necessary for a daily maintenance log entry. The measured weight for 333g field is an 
entry screen. The weight, 333g, is an example of the calibration weigh used. The field 
would show the actual facility-defined weight #1. Likewise, the measured weight for 
666g is a similar entry field. The notes field is a free-form entry field. 

When the user scans the instrument, the device goes to page 2 (Figure 100b). 

1 5 If the user clicks "Next," the device goes to page 3 (Figure 100c). If the user clicks 
"Cleaned instrument" or "cleaning not necessary," the device goes to page 4 (Figure 
lOOd). If user scans the correct operator ID, the device logs the entries. If the weights 
are within the facility-defined % acceptable error from the actual weights, then the 
device goes to page 6 (Figure lOOf). Else the device goes to page 5 (warning) (Figure 

20 lOOe). If the user clicks "Again," the device goes to page 1 (for a new log entry). If 
the user clicks "Out of Service," the device goes to the out of service screen. If the 
user clicks "Done," the device goes to the main menu. 

The weekly maintenance screen (Figure lOla-lOlh) allows the user to enter 
the data necessary for a weekly maintenance log entry. Pages 2-5 (Figures lOlb-lOle) 

25 do not result in any logged data. They are reminders only. However, if any of the 
items fail, that item is logged as the failure. 

The scan machine field comprises the scanned instrument ID. The notes field 
is a free-form entry field. The maintenance field is a display comprising the either 
"PASSED" or "FAILED." 

30 If the user clicks "PASS," the device goes to the next screen in sequence. If 

the user clicks "FAIL," the device skips directly to page 6 (Figure lOlf) and 
remembers the description of the failed procedure. If the user scans the correct 



61 

operator ID, the device logs the entries. If "FAIL" had been clicked for any item, the 
device goes to page 8 (Figure lOlh). If all items passed, the device goes to page 7 
(figure lOlg). If the user clicks "Yes," the device goes to page 1 (for a new log entry). 
If the user clicks "Return to menu," the device goes to the main menu. If the user 
5 clicks "OK" on page 8, the device goes to the out of service screen, page 2 (assumes 
same instrument). 

The monthly maintenance screen (Figures 102a-102h) allows the user to enter 
the data necessary for a monthly maintenance log entry. Pages 2-5 (Figures 102b- 
102f) do not result in any logged data. Rather, they are reminders only. However, if 
10 any items failed, the description of the failed item is logged. 

The scan machine field comprises the scanned instrument ID. The notes field 
is a free-form entry field. The maintenance field is a display comprising the either 
"PASSED" or "FAILED." 

If the user clicks "PASS," the device goes to the next screen in sequence. If 
1 5 the user clicks "FAIL," the device skips directly to page 6 (Figure 102f) and 
remembers the description of the failed procedure. If the user scans the correct 
operator ID, the device logs the entries. If "FAIL" had been clicked for any item, the 
device goes to page 8 (Figure 102h). If all items passed, the device goes to page 7 
(Figure 102g). If the user clicks "Yes," the device goes to page 1 (for a new log 
20 entry). If the user clicks "Return to menu," the device goes to the main menu. If the 
user clicks "OK" on page 8, the device goes to the out of service screen, page 2 
(assumes same instrument). 

The field service screen (Figures 103a-103d) is where the user enters the data 
necessary for a field service log entry. The scan machine field comprises the scanned 
25 instrument ID. The reason field is a facility-definable pick list field. The notes field is 
a free-form entry field. 

If the user clicks "Yes," the device goes to page 4 (Figure 103d) (skips page 3). 
If the user clicks "No," the device goes to page 3 (Figure 103c). If the user clicks on a 
reason on page 3, the device goes to page 4. If user scans the correct operator ID, the 
30 device logs the entries and goes to the main menu. 

The out of service screen (Figures 104a- 104c) is where the user enters the data 
necessary for an out of service log entry. The log entry disables further use of the 
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instrument. The scan machine field comprises the scanned instrument ID. The reason 
field is a facility-definable pick list field. The notes field is a free-form entry field. 

If the user scans the instrument, the device goes to page 2 (Figure 104b). If the 
user selects a reason, the device goes to page 3 (Figure 104c). If the user scans the 
5 correct operator ID, the device logs the entries and goes to the main menu. 

The back in service screen (Figures 105a-105f) allows the user it enter the data 
necessary to enter the data for a back-in-service log entry. The scan machine field 
comprises the scanned instrument ID. The part number replaced screen is an entry 
field where the user enters a part number. The description field is a display field based 

10 on a lookup using the part number entered or "not found" if the part number is not 
found. The technician field is an entry field comprising the name of the technician. 
The reason and part fields are a facility-definable pick list fields. 

If the user scans the instrument, the device checks if a field service report was 
logged since the last time an out-of-service was logged. If so, the device goes to page 

15 3 (Figure 105c). If not (error condition), the device goes to page 2 (Figure 105b). If 
the user clicks "Ignore warning," the device goes to page 3 (Figure 105c). If the user 
selects a reason, the device goes to page 4 (Figure 105d). If the user clicks "OK" on 
page 4, the device looks up the part number entered, and goes to page 5 (Figure 105e). 
If the part number is not found, the device displays "Not found" for description. If the 

20 user clicks "No part replaced," the device goes to page 6 (Figure 105f). If the user 
scans the correct operator ID, the device logs the entries and goes to the main menu. 
Instrument Data 

i\0^7 ^ hc 5y3tcmJ0 also allows a fdiilily lo galhei dald fiuni the labuiatuiy — 
instruments. This data^ean be monitored in real time, or near real time, from remote 

25 locations, the workstation(sXor the PDAs. The present system has the ability to 
convert parallel data to Ethemerwhich allows the data to be seen using a common 
web browser. This enables present system to be integrated into existing blood 
collection facilities that utilize legacy apheresis instruments having a proprietary pin 
arrangement, such as the Autopheresis-C plasmapheresis instrument supplied by the 

30 Fenwal Division of Baxter International. The asrta conversion is accomplished by the 

Typically, an Autopheresis-C apheresis instrument transmits parallel data at 
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fixed intervals. Each data sample consists of a binary stream. The data transmission 
limitations of an Autopheresis-C communication are overcome by the serial/parallel to 
Ethernet converters 24a 5 24b, 24c. The converters 24a, 24b, 24c are add-on circuit 
boards that repackage the Autopheresis-C data sample into an IP/UDP packet for 
transmission over the first Ethernet 30. From a network point of view, the converters 
24a, 24b, 24c are nodes, although the source of data comes from the instruments 20a, 
20b, 20c. The converters 24a, 24b, 24c act as a pass-through of instrument 20a, 20b, 
20c data samples to the system server 34. 

An Autopheresis-C is typically designed to operate in transmit mode only, 
although a hardwired signal line between each Autopheresis-C and each converter can 
be used to communicate network data to the Autopheresis-C. Such data may originate 
from the system server 34 in the form of acknowledgment data, which then passes 
through the converter to the Autopheresis-C. 

There are several types of data packets transmitted from the instruments 20a, 
20b, 20c to the system server 34. The formats for all of the packets contain header 
information about the actual length of data that they encapsulate. A first type of 
packet contains diagnostic information, including crash reports, stack and ram dump. 
The data are sent once in continuous blocks at power-up of the apheresis instrument. 

A second type of packet contains run information and is sent is sent 
approximately 10 times per second (unless replaced by a configuration packet, as 
described below) after power up and initial start up (lasting approximately 5 seconds) 
of the instruments 20a, 20b, 20c. This occurs throughout the power-on state of the 
instruments 20a, 20b, 20c, whether it is in a bleed or not. A modecode field of the 
packet of the second type is examined to determine the state of the machine. Each run 
packet includes a first echo field that the instruments 20a, 20b, 20c expect the system 
server 34 to echo back in a data packet within 10 seconds after it was transmitted by 
an instrument 20a, 20b, 20c. 

A third type of packet contains configuration data. This packet is sent in place 
of a run packet at predetermined intervals. At each of the intervals, the configuration 
packet is sent 5 times, once per second (over a 5 second total) every 6 minutes, and at 
specific states of the machine, such as power-up, before the venipuncture is.expected, 
and at the end of a bleed. 
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Additional data packets, called network management packets, are transmitted 
on different ports than the diagnostic, run, and configuration packets. A first network 
management packet is transmitted from the converters 24a, 24b, 24c to the system 
server 34. This packet is generated by a converter and received by the system server 
5 34 and is the first packet to be sent after a converter reboot (after bootp reply). 
Thereafter it is repeated every 8 seconds (with redundant duplicates). This packet 
provides information about communication status. 

A second network management packet, or reset packet, is transmitted from the 
system server 34 to each converter 24a, 24b, 24c. This packet is sent as a broadcast 

10 out of a port on the system server 34 when the system server 34 boots, or can be sent 
to an individual device. The reset packet causes the converter to reboot. 

A third network management packet, or parameter packet, is sent by the system 
server 34 primarily to signal to an instrument 20a, 20b, 20c that the system server 34 
has received the run packets. The system server 34 is expected to the parameter 

15 packet every 3 seconds. The parameter packet contains the first echo field response to 
the run packet. Each parameter packet further includes a second echo field that the 
instruments 20a, 20b, 20c echo in the run packet, and a third echo that the converters 
24a, 24b, 24c echo in the information packet. The system server 34 can use these 
echo fields to determine of the last parameter packet transmitted by the system server 

20 34 was received by either the converters 24a, 24b, 24c or the instruments 20a, 20b, 
20c. 

In a typical scenario, an apheresis instrument is booting when the system 
server 34 is already running. First, the converter 24 boots. At reset, an indicator lamp 
flashes. The converter 24 sends bootp requests until it gets a broadcast reply from the 
25 system server 34 assigning it an IP address. Once the converter has an IP address, it 
will send an information packet to gather apheresis instrument data and transmit the 
data to the system server 34. The converter will timeout and reboot when it detects no 
apheresis instrument activity after 3 seconds, or no system server 34 activity after 8 
seconds. 

30 The converter boot is relatively quick. Once the converter boot is completed, 

the converter waits for the apheresis instrument to boot. 

Once the converter boot (bootp) is completed and after the system server 34 
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has received the information packet from the converter, the system server 34 sends a 
parameter packet to the converter. 

On power up, the apheresis instrument sends a diagnostic packet to the system 
server 34. If the diagnostic packet includes a non-functional report, the system server 
5 34 disables the apheresis instrument. 

Next, the apheresis instrument sends a configuration packet to the system 
server 34. Thus, the system server 34 receives an information packet, a diagnostic 
packet, and a configuration packet shortly after the apheresis instrument boots. 

Generally during a bleed procedure, a first indicator lamp or LED flashes as 
10 the converter sends Ethernet packets to the system server 34. A second indicator lamp 
or LED signals when data collisions occur. An apheresis instrument sends a run or 
configuration packet at predetermined intervals. The majority of the data traffic on the 
first network 12 is made up of run packets. Configuration packets are interleaved at 
specific intervals as described above. The system server 34 sends a parameter packet 
15 at predetermined intervals (asynchronously with run packets), and the converter sends 
an information packet at predetermined intervals (asynchronously with the run 
packets). 

The converters 24a, 24b, 24c reset on several conditions. In every case, an 
indicator lamp or LED will signal when a reset occurs. The converters 24a, 24b, 24c 

20 reset when no apheresis instrument packets are received for 3 seconds. The converters 
24a, 24b, 24c also reset when the system server 34 sends a reset packet, when an 
internal software fault causes a hardware reset, and when no system server 34 packets 
are seen for 8 seconds. 

During a system server 34 outage, the converters 24a 5 24b, 24c will 

25 continuously reset until the system server 34 application starts up again. When the 
system server 34 application broadcasts a reset packet, all of the converters 24a, 24b, 
24c reset, and the boot procedure continues as if the system server 34 was booted first, 
and all the converters 24a, 24b, 24c were booted later. 
Practical Example 

30 Referring to Figure 95, a method of using the apparatus of the present 

invention for automating the workflow within a blood collection facility is illustrated 
in flowchart format. This method includes monitoring the apheresis processes for the 
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occurrence of specific events, and routing data regarding these events to PDAs or 
personal mobile devices for operator-assisted logging. The data provides a snapshot 
of the operational status of the apheresis instrument and is stored along with the 
logged event. Additional events can be logged directly on the PDAs through menu 
5 selections. The system also provides a means for performing verification of input data 
logged with each event. 

The data snapshots can be displayed on a web browser in real time or near real 
time. The system also provides HTML-based query and reporting of aggregate data 
from the logged events and snapshots. Open standard protocol is provided for 

10 transferring the aggregate data from/to other blood facilities' computer systems. The 
aggregate data can be used to drive business decisions in operator training, inventory 
management, donor recruitment, and machine maintenance and servicing. 

The method of the present invention begins with a donor walking into the 
donation site. The donor produces his ID card. The receptionist scans the donor ID 

15 card. An RF handheld terminal/web client, a PDA, with a built in bar code scanner is 
used to prompt the screener to scan the donor ID card bar code. The system server 
verifies the donor ID by searching a database and displays an eligibility outcome. The 
database search is made automatically when the donor ID card is read. The donor ID 
input causes a uniform resource locator (URL) to run and connects the web client to a 

20 hypertext transfer protocol (HTTP) server via a wireless link. The system server runs 
an application to search against a national donor eligibility database or, alternatively, 
the central server's DMS. The result is returned to the client application. The result 
of the search is returned instantaneously. If the donor is not eligible, the computer 
displays the eligibility date for this donor, and the donor is deferred. Otherwise, the 

25 site receptionist prepares to take the vital signs and medical history of the donor. 

Next, the vital signs and medical history of the donor are transmitted to a 
donor screening database. The donor vital signs are input and stored in a donor 
screening database. This is accomplished by entering the vital sign data in an HTML 
form located on the handheld terminal. The form is then submitted to the system 

30 server via the mobile module. 

Similarly, responses to a donor medical history checklist are entered 
electronically. The medical history data are entered on an HTML form on the 
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handheld terminal. The form is then submitted to the system server. 

Donor eligibility is automatically derived based on the input donor ID, the 
input donor vital sign data, and the donor's medical history data . A set criteria for 
eligibility is predetermined and configurable within the database on the system server. 
5 The system server runs an application to verify against the set of criteria and returns 
the outcome to the client. 

If the donor's vital signs are acceptable and the donor is eligible, an identifier 
such as a bleed number is generated and queued in a scheduling database. The 
scheduling database now points to or has access to donor demographics, vital signs, 

10 and medical history, and the donor's weight is used by the system server to calculate a 
nomogram; i.e. the volume of blood or blood component to collect. However, if the 
vital signs are unacceptable, the donor is again deferred. 

The bleed number and the donor ID may be identical. However, the bleed 
number is preferably a unique identifier that is generated once for each separate 

1 5 donation. A unique bleed number allows the system to differentiate between different 
bleed or collection procedures performed at different times on the same donor. This is 
important for traceability and donor evaluations, for example, tracking when the donor 
last underwent a bleed or collection procedure. 

If the donor is accepted, the system server runs an application generated for a 

20 qualified donor and returns the approval to the client. The bleed number is printed on 
a bar code label using a portable printer attached to the handheld terminal. The bleed 
number is linked to the DMS. The system server creates a donation data file indexed 
on the bleed number. The donation data comprises the bleed number, the donor's vital 
signs, and the donor ID. The bleed number is queued and maintained electronically 

25 for daily scheduling. The system server maintains a FIFO list of active bleed numbers 
for the daily schedule. A count of the number of pending donations is also 
maintained. Bleed number ranges can be allotted at regular intervals before given out, 
and can be tracked based on lots, among other tracking methods described herein. 
All PDA/scanners and apheresis instruments have network access to the 

30 database server(s), including the daily scheduling data. Accordingly, each instrument 
is a net appliance with an IP address. The instruments communicate over wire links 
and wireless links with a bridge sitting on a wired network. Each PDA/scanner and 
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monitoring personal computer, thus, functions as a web client. In a preferred 
embodiment, the instruments are set up to send out data, including events and other 
data taken during the collection process, at regular time intervals to the facility server, 
which in-turn can send such information to the main system server, and related 
5 databases. Another contemplated embodiment includes using a server directly on the 
instrument. One PDA/scanner function includes being able to mimic the actual screen 
display at any point in real time, of each networked instruments, when the 
PDA/scanner is set to view such information. 

If an apheresis instrument is available, and the bleed number queue is not 

10 empty, a phlebotomist transmits a request from the apheresis instrument to the 

database. The first available bleed number from the queue is then removed from the 
queue and allocated to the available apheresis instrument. 

An LED display at the apheresis center's reception area blinks the current 
bleed number and the apheresis instrument that is available. This instructs the waiting 

15 donors to proceed to the available instrument. 

Therefore, each apheresis instrument includes a method for the phlebotomist to 
send a request for a donor to the scheduling database. The phlebotomist pushes a 
request button which causes a URL to run and connect to the system server. In 
response to the request for a donor, the scheduling database returns a bleed number to 

20 the apheresis instrument. This is accomplished as an application runs on the server to 
retrieve the next available bleed number. The relevant donor information is retrieved 
and returned to the apheresis instrument or PDA by another application. 

In addition, the apheresis instrument or a PDA has a method to notify the 
scheduling application the apheresis instrument's readiness to accept a donor. Here, 

25 the phlebotomist pushes a button which causes a URL to run and connect to the 
system server. In response to the apheresis instrument. ready notification, the 
instrument identity and bleed number is broadcast on a public display system. Here, 
an application is run on the system server to output the instrument identity and the 
bleed number to the public display system. 

30 Future apheresis instruments may be capable of configuring themselves based 

on the donor information received. The instrument would read the donor information 
received from the system server and load a system configuration file. Here, the bleed 
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number is inputted into the ready apheresis instrument for verification, instead of the 
PDA/scanner. 

Before each action is taken by each operator (such as a phlebotomist) at each 
instrument, the operator scans (can be a requirement) their own ID card/badge, and the 
system tracks all actions performed by that operator, and at each instrument, are 
associated with the operator ID code. The operator typically must scan the machine 
code first, or vice versa. 

Next, at the apheresis instrument or PDA/scanner, the bleed number is scanned 
by the phlebotomist. This bleed number must match the information retrieved by the 
PDA or the instrument from the system server. The bleed number is read into the 
apheresis instrument or PDA/scanner and compared with the donor information 
previously downloaded from the server. 

The phlebotomist via the PDA or the apheresis instrument notifies the 
scheduling database when a donor has been accepted at the apheresis instrument. A 
bleed number match causes a URL to run and connect to the system server. The 
system server then updates the waiting list of donors by removing the donor from the 
list by running an application to remove the bleed number from the queue. Thus, the 
daily donor schedule is updated. 

Some of the donor acceptance criteria are input from a separate customer 
system and others are set up as a general rule for the facility. For example, the facility 
system communicates information to the central server such as the donor ID that has 
just been registered, the unique bleed number, and the donor's weight. When the 
donor arrives at the bedside, his barcoded ID and bleed number are scanned by the 
PDA/scanner to match what the server is expecting. The donor's weight is used by the 
operator to calculate a nomogram. When the operator enters the nomogram, the input 
is electronically transmitted to the system server which compares the nomogram to the 
system server's calculation. If a match is not found, the system server warns the 
operator of the error. 

The phlebotomist then scans a blood collection kit's (i.e. a disposable 
kits/solutions/transfer pack) identification code, usually a bar code, and enters the 
relevant information to begin the apheresis procedure. All input and output data 
associated with the apheresis procedure are stored in the database. These include the 
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access site, the collection volumes, solution volumes, start and end times, donor 
reactions, and blood/plasma losses. A bar code scanner is, thus, either attached 
directly to the apheresis instrument or the PDA is used to collect and transmit the 
information. 

5 The apparatus and method of the invention also provides a precheck of all of 

the disposable kits/solutions/transfer packs used in the blood collection for 
acceptability before a bleed (procedure) can begin. The system server also verifies 
that the disposable kits are the right type and within expiration date, the operator is 
authorized to perform the procedure, and the apheresis instrument is approved. This 

10 accomplished by comparing this data with the data configured in the system server for 
the facility. The lot information may also be verified against a valid lot list on the 
system server, if one is maintained. This way the apheresis instrument can reject a lot 
if it has been recalled. If the disposable kit fails the precheck, a warning is transmitted 

by the system server. 
1 5 The apparatus also tracks usage and inventory of disposable 

kits/solutions/transfer packs. Inventory of the disposable kits/solutions/transfer packs 
is tracked via an inventory application. The instrument immediately notifies an 
inventory application of the disposable kits/solutions/transfer packs' usage. The bar 
code input cause URLs to run and connect to the system server. The inventory 
20 application updates the supply level based on usage. The system server runs an 
application to update a supplies inventory database. The system server invokes an 
additional connection to an external server at a supplier's facility. The supplier's 
server in turn updates its orders database. 

As described above, the operator logs his/her identity into the system server 
25 through the PDA/scanner. The system also includes a database of the phlebotomists' 
qualifications. For example, certain operators are only qualified to perform certain 
procedures. When an operator attempts to log in his/her identity and perform a 
planned blood collection related procedure for which he/she is not unqualified to 
perform, the system server will produce a warning, or alternatively, prevent the 
30 procedure from continuing altogether. 

The apparatus provides an automatic trace from the bleed number to all inputs 
and outputs that are involved in the collection of blood or blood components 136. 
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Thus, the bleed number can be traced to the donor, the disposable kits, the facility 
operator, and the apheresis instrument. This has not been possible, or was a very 
laborious task. 

For the traceability to be accurate, all information must be linked or synched 
5 with the apheresis instrument and the bleed number. Therefore, each apheresis 

instrument has a unique serial number programmed into its memory. Each instrument 
also has a bar code label associated with it which may or may not be the same as its 
serial number, and a media access control (MAC) address programmed into the 
NetDev connected to the apheresis instrument. As phlebotomist goes through the 

10 administrative set up function which sets up the apheresis instrument. The serial 

number, bar code and MAC address are entered into a table within the system server 
to identify the apheresis instrument. When the apheresis instrument is powered up, it 
sends the bootp request to the system server, which in turn returns an IP address to the 
instrument. From then on, the data packets from the instrument are identified by the 

1 5 system server through apheresis instrument's IP address. 

This is all transparent to the phlebotomist. From the phlebotomist' s point of 
view, he/she scans the bar code on the apheresis instrument to set up the apheresis 
instrument and prepares for a bleed procedure. The system server looks up the serial 
number of the apheresis instrument from the bar code, and creates a bleed record with 

20 the donor bleed number, donor ID, the instrument serial number, and the identity of 
the disposable kit(s) used. Every time a data packet is received from the apheresis 
instrument, the system server also looks up the apheresis instrument's serial number 
(IP to MAC to serial number) and inserts any relevant information into the 
corresponding bleed record. 

25 The system also routes apheresis instrument information to the PDAs based on 

the apheresis instrument that is assigned to or associated with an individual PDA. 
This is used like a paging system. This enables the phlebotomists to log predefined 
events (such as instrument alarms) with only a few key strokes. The system is flexible 
enough to log events from different vendor's instruments. The specific target routing 

30 is performed when the phlebotomist scan the apheresis instrument bar codes at the 
beginning of a procedure. Since each data packet is traceable to the ID of the 
originating apheresis instrument, and each PDA has its own network ID, the system 
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server can identify which PDA to route the information to. 

The pre-processing (pre-venipuncture) configuration of the apheresis 
instrument is recorded electronically. The information is stored locally on the 
instrument and transmitted to the system server at the end of the collections. 
5 Alternatively, just prior to venipuncture, the instrument configuration is submitted as 
an HTML form to the system server. The system server then runs an application to 
write the information into a configuration database file. 

The statistics and summaries at the end of the collection are also stored 
electronically. The information is submitted as an HTML form to the system server. 
1 0 The system server then runs an application to write the information into a donation 
database file. The system server also maintains a count of the total number of blood 
product units collected for the day. 

The system may provide statistics of a procedure execution that is linked to a 
phlebotomist or phlebotomists, e.g., the events the operator handled, the operator's 
1 5 error rate (whether they resulted in instrument alarms or not), how many procedures 
the operator has performed, etc. This provides a means for focused training of 
individual operators. 

The system also captures the history of keystrokes performed on the 
instrument. This can be used later for troubleshooting of instruments or procedures. 
20 Procedural exceptions (alarms and/or adjustments) during collection are 

recorded electronically. The information is stored locally on the apheresis instrument 
and transmitted at the end of the collection. Alternatively, whenever an exception is 
performed, the information is submitted as an HTML form to the system server. The 
server then runs an application to write the information into a procedure exception 
25 database file. 

The apparatus also logs the apheresis instrument's cumulative operating hours, 
calibration, and any service maintenance performed, as well as any malfunctions 
and/or error occurrences. Each instrument records its cumulative operating hours, 
calibration and other service maintenance performed, as well as malfunction and error 
30 occurrences in its internal memory. On a weekly base or otherwise, an application 
runs to collect these records from the instruments. This is done by running a URL 
which connects to the instrument. The instrument in turn runs an application to return 
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the records. Based on the returned records, the application makes a recommendation 
on service call on each instrument. 

The apparatus records blood/plasma loss during a collection. Automatic 
reports are generated to the appropriate establishments when the loss is greater than 
5 acceptable limits. The instrument monitors and calculates blood/plasma loss during a 
collection. The information is transmitted as part of the summary record at the end of 
a collection. When an unacceptable blood/plasma loss record is received, the system 
server connects to the central server and submits a donor deferment report. Other 
reports pertaining to any of the inputs or outputs may also be requested and generated. 

10 Next, each apheresis instrument's operation can be monitored at a central 

workstation, generally a web client or the system server, or through the PDA/scanner. 
The operator configures a list of parameters for real time display. If necessary a 
message or instruction can be transmitted by the operator to a specific instrument for 
display. The workstation can also check the total units of blood components collected 

1 5 for the day, as well as the number of donors on the waiting list. 

The workstation monitors parameters associated with the collection process on 
each apheresis instrument. Accordingly, the monitoring workstation communicates to 
all of the PDA/scanners and apheresis instruments within the apparatus via a wired or 
wireless network. 

20 The apparatus routes instrument information to the PDAs based on the 

apheresis instruments that are assigned to the individual PDAs. This allows operators 
to view and log predefined events (such as instrument alarms) with only a few key 
strokes. The specific target routing by the system server is done is accomplished when 
the operator scans the apheresis instrument barcodes at the beginning of a procedure. 

25 Since each data packet for the apheresis instrument is traceable to the identity of the 
apheresis instrument, and each PDA has its own network identity, the system server 
can route the information to the proper PDA. 

The workstation application sets up a list of parameters to monitor based on 
user preference. The application runs a URL/web query to the system server running 

30 on the instrument. The instrument runs an application to read the requested 

parameters and returns them to the application. A Java applet runs at the workstation 
to provide continuous trending of the data received. Alternatively, a stream server is 



74 



implemented on the instrument and data are continuously streamed to the application 
and updated in real time. ASP's are implemented on the instrument. An ASP is a 
specification for a dynamically created web page that utilizes ActiveX scripting. 
Dynamic hypertext markup language (DHTML) is run on the workstation to display 

5 data dynamically. 

The workstation also communicates messages to the apheresis instrument. The 
workstation application submits an HTML form containing messages to the 
instrument. An application runs on the instrument to display a pop up message. 

The workstation also has a function to display the cumulative blood product 
10 units collected, as well as the total number of donors in the waiting list. The 
workstation application displays live real time statistics through a java applet, 

streaming, or DHTML. 

Blood and blood component inventory can be tracked by the system. When 
the apheresis collection is completed, a bar code label identifying the product and 
1 5 volume is printed and affixed to the product. The blood product then moves to a post- 
processing area such as pathogen inactivation. A different bar code label can be 
printed and affixed to identify it as having been post-processed. The blood product 
then moves into the freezer storage area, where each incoming unit is scanned and the 
corresponding product inventory database is updated. 

The instrument prints a bar code label containing necessary information 
identifying the product. The instrument includes a function to print bar code labels on 
an attached printer. The apheresis instrument prints a bar code label identifying the 
product as being processed. Accordingly, the apheresis instrument also includes a 
function to print bar code labels on an attached printer. 
25 Incoming blood products are identified electronically prior to entering the 

freezer. A bar code scanner is provided to scan incoming blood products. The blood 
product inventory is updated for each unit stored in the freezer. Each bar code read 
from a product unit triggers a URL with the bar code information sent to the system 
server. The system server then runs an application to update the product inventory. 
30 Next, the blood product stays in the freezer area until lab test results of the 

blood or blood component collected are received. At the shipping area, each blood 
product unit is scanned and compared with the lab test database and other release 
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requirements. All approved product units are then packaged into a shipping box 
designated for a certain destination. The center inventory database is updated with the 
outgoing units, while the end user gets informed of the shipment immediately. 

A sample test report is used to electronically identify blood product units for 
5 release. The sample test report is downloaded to an application on a daily basis. The 
bleed number on each blood product unit is scanned and verified with that of the 
approved test sample list. A unit can be released if a match is found. 

The contents and destination of each shipping box is identified. Each blood 
product unit is scanned before going into the shipping box. When the capacity of the 
10 box is reached, a shipping label is printed. A record of each shipping box 
identification and its contents are also stored in a database 

Finally, the blood product inventory is maintained up-to-date. A blood product 
inventory database is updated with each outgoing unit. When a box is scaled and 
confirmed, a URL runs to connect to an external server at a customer's site. A data 
1 5 file containing these records is transferred to the external server. The external server 
then updates its inventory receivables list. 

It should be understood that when the word "scanned" or "scanner"is used 
herein, it is contemplated that such actions and information can be entered in another a 
manner, such as through a touch screen keyboard, and vice versa. 
20 The above-described invention can also be implemented and used within a 

blood testing and pathogen inactivation facility/system, and/or within a fluid tracking 
system. 

It is further contemplated that all of the features and advantages of the 
PDA/scanner type device can be implemented directly into the instrument (apheresis 
25 or other instrument). 

It will be understood that the invention may be embodied in other specific 
forms without departing from the spirit or central characteristics thereof. The present 
embodiments, therefore, are to be considered in all respects as illustrative and not 
restrictive, and the invention is not to be limited to the details given herein. 



